In the tutorials section you will find two very simple examples of

TDD is a software development methodology where the requirements are converted into test cases before the functional implementation written.

  1. Gather requirements

  2. Create test cases

  3. Write the test

  4. Write the functional implementation

  5. Run the test

  6. Refactor until all test passes

People who are new to testing might find this intimidating but if you look at the above sequence, it is an incredibly natural way to proceed.

If you look at steps 1. and 2. it should be clear that these steps could be carried out independently of the developer. So while the developer is working on some other piece of functional code (which they enjoy more), the PO or Domain Expert

  1. is formally responsible for defining a quality requirements definition (which is their responsibility anyway).

  2. can define the inputs and outputs to be used to cover all test cases.

  3. generate the actual test cases if they are supported by a tool like DevMate.

Black Box Testing

You have probably heard about black box testing. If you are using TDD then you are, by definition, black box testing.


Equivalence Class Partitioning & Test Cases

The word is a bit scary, but the process is not. Equivalence Class Partitioning is the process of defining Equivalence Classes (sorry). This means we need to find all of the the necessary inputs to our method under test that will test all the requirements.

Note that this does not by definition mean 100% code coverage, but if your are using TDD properly and the developer has coded against the requirements, you should get 100% code coverage within the method under test.

Visualizing with DevMate

DevMate is a very good way of not only handling the whole process right through to test code generation, it also helps us visualize the process of Equivalence Class Partitioning and the Test Cases.

  1. The method under test

  2. The parameter (there can be multiple parameters of course)

  3. The Equivalence Classes

  4. The possible outputs from our method under test given the given input Equivalence Classes

The test cases, the columns to the right, are generated with a button press based on defined inputs and outputs. You can see, for each test case, how the outputs have been defined to correspond to the inputs.

This table can be easily understood and even created by the PO, QA Engineer or Domain Expert, not just the developer. Where you are dealing with complex arguments, factory methods or custom assertions, you it would require the developer or a technical QA Engineer.

If you want to see this in more detail, please see Detailed configuration - step-by-step.

Write the unit test

With the requirements and test cases defined, we now write the unit test, even though we haven’t written any functional implementation of the method.

We won’t show a unit test being written as it’s beyond the scope of this page.

Generate the test automatically with DevMate

If you’ve defined your test cases in DevMate, generating the code is the press of a button. At this stage, your test would fail because you’ve not coded the implementation.

Functional implementation

You can now code your implementation. Once you’re done, you re-run the test → refactor → re-run the test until your test (and all of its test cases) pass.


If you’re in pursuit of the highest quality, TDD is a superb way to go. Despite seeming foreign and intimidating to testing novices, it is surprisingly natural to use. In the medium and long term it will, without doubt, save you a lot of time even if you are a little bit slower in the short term.

DevMate can save developers up to 50% of the time spent writing tests and it encourages more people in the product team to take ownership and share the responsibility for more of the testing process.

Detailed configuration - step-by-step explains this in detail.