Test First Development

Test first development is a development style where write unit tests before writing the production code.

Simple steps of Test First Development:
Simple steps for Test First Developments are

+. Write the specification
+. Write the tests to the specification
+. Write the code until the entire test passes

We can simplify above steps as follows (here we didn’t mentioned specification writing)

+. Add a test basically just enough code to fail.
+. Run the test
+. Update production code to make it pass the test.
+. Run the test again. In this case

@. If test fails then update functional case and retest
@. Else start over i.e. write another test and follow above steps.

Following UML diagram shows the Test First Activities:
However sometimes above steps doesn’t helpful to telling how to do it. So we’ll present some steps in a way that actually useful for get work accomplished.
Steps for Test First Programming

+. Think about what you want to do
+. Think about what it looks like from customer’s perspective including API
+. Think about how to test it.
+. Write the happy path test cases.
+. Write the production code.
+. Expand the tests for more complete behavior coverage.
+. Write production to make the test pass

Now we’ll explain shortly above these steps:
+. Think about what you want to do

@. Collect requirements.
@. Define the feature.
@. Try to understand what customer problem the feature is solving.
@. What are the real core requirements to solve the problem.

Features often expand in scope as development proceeds. Just start with minimum viable scope for that feature. Then expand iteratively after have something working.

+. Think about what it looks like from customer’s perspective including API

@. What’s the API going to look like?
@. Does this solve the customer problem?
@. Is it clean?
@. Is it awkward?
@. Can you imagine using it?
@. Is it easy to explain?


@. What is it going to look like?
@. What input elements are needed?
@. Are they really needed?
@. Is it reasonable for the user to know the information you are asking?


@. Involve a usability engineer if available
@. Tell some verbally

-+. What the purpose of the feature is
-+. How to use the feature
-+। What they should see

Then carefully listen their questions and feedbacks

If anything to change after doing this all then change them easily because no production code written yet.

+. Think about how to test it

@. How do we know if the feature works?
@. How do we know if it is not working?
@. What can go wrong? Can we check for that?
@. What is the mission critical part of the feature? How can this be tested?
@. Is any API missing to allow automated tests to interrogate the system for error conditions?
@. What is the riskiest part of the feature? How can this be tested?

+. Write the happy path test cases.

@. Writing the tests allow you to use the API.
@. Write enough tests to satisfy the following:
-+. The full feature is being tested the way a customer would use it.
-+. Every function of the API is being used by at least one test.


@. If the API is cumbersome, the tests will be a pain to write. If so, change the API. Make it easier to use.
@. Are there functions left over that you didn’t need to use? Can you remove this API function without limiting the user? Then do so.

+. Write the production code.

@. Write the production code to make one test pass.
@. Keep going until the entire tests pass.
@. If your test framework supports xfail, you can mark all of the tests as xfail at first and remove the mark one at a time.

+. Expand the tests for more complete behavior coverage.

@. Look at the set of tests you have, the feature, the API.
@. Be as behavior complete as you can be.
@. Are there error conditions that haven’t been tested for yet?
@. Make sure the mission critical and the risk area parts identified in step 3 are fully tested.

+. Write the production code to make the tests pass

Pretty self explanatory. Go fix the code.

Why Test First?
In complex software uses of TDD or Test First is undeniable. Before done the software tests are very essential. One can write tests after write the code. But there are some really good reasons to write the test first. They are

1. You can use the tests to guide you in what to code next.
2. You can use the tests to tell you when you are done coding, and help avoid feature creep.
3. If it’s the same person writing the tests and the production code, then the assumptions you made while writing the code will color how you write the tests and you’ll miss ways to use your code. Writing the tests before you write the code will mitigate this somewhat.
4. Thinking about and writing tests help you understand the specification.
5. Cumbersome parts of the API can be fixed before the API is implemented.
6. Holes and inconsistencies in the specification are found out early.
7. The tests will get written. If you put off the tests until after your code is “done”, there is a reasonable chance that you will ship that code before the tests are done. And then your customers will find your bugs that your testing could have caught.

Md. Mojammel Haque
Currently working as Lead Team (Application Architecture) at Raven Systems Ltd.

Passion for software development especially agile practices such as TDD & BDD with in depth knowledge of OOP, DDD, CQRS, ES, GoF, SOLID and PoEAA.

Over 6 years of software development experience ASP.NET. Has the ability to understand and transform complex business requirements into software ensuring applications are delivered on time.

Also experience in non Microsoft .NET technologies such as Dapper.Net, Subversion, Structure Map & AngularJs.

360 Total Views 3 Views Today
Unit Testing Frameworks
Test driven Development

Leave a Comment

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>