Riding the TDD/BDD Process – Part I

For a long time, I have been reading about TDD, learning various test automation techniques but as an architect, I had very few chances to actually work in a TDD project. So when I recently got a request to help a team, who is going to ride a TDD process in their project, to understand how Microsoft’s technology stack supports TDD, I am far more eager to jump in and see how it goes along with them. On another project where the team had absolutely no experience with test automation, I recently spoke about various benefits of test automation. So here I am between a team with no test automation and a team starting their TDD journey. So in this post and if required few more posts, I am planning to document what I know and what I am going to find out along the way.

Why of Test Automation

Let’s start with Why. Today in most of the IT services companies developers say that they are doing unit testing. However most of this unit testing is casual and gut feeling based. Developers believe that their code will not break and that includes me as well. The rigor many times is limited to initial testing. Once that phase is over, they probably test only for the changes. So the first reaction when the tester logs a bug is of disbelief. Then they say it is not their fault, the requirement is not like that and finally after triage they succumb and accept the bug. However somewhere in their mind, they are cursing the testers, frustrated that they have missed the timelines, have to work late hours etc.

When I talk to project teams and tell them that in today’s time there is literally no distinction as a developer and a tester. Each developer must know testing fundamentals and each tester must know enough of development that they can automate test cases, the first reaction is of shock that this is absolutely impractical. A developer doing testing is kind of degradation

However, come to think of this. If you understand that testing the code is required and someone is going to do it, why that other person is not yourself.

Why should you let someone else humiliate by throwing trivial bugs at you and make mockery of your skills?

The benefits of the developer doing unit test automation are enormous. It adds some effort on the development front but it pays every time you make change to your code. I recently came across a small book on unit testing published by Syncfusion called Unit Testing Succintly. The author gives a very detailed analysis of what code should be called as unit and gives examples of the code which cannot be called as unit vis-a-vis same code when refactored turns into small units.So once you divide the code into these small units, you automatically improve the code quality because you can easily follow two principles of coding, DRY (Don’t Repeat Yourself) and SR (Single Responsibility)

The immediate benefit of automated unit testing is improvement in code quality

The other challenge with manual testing is you tend to test less. Less tests and even lesser regression. I really do not want to go why what the quality documents say but the reality is that developers are lazy and manual testing records are really do not backed by strong evidence they are merely trust. There is very limited traceability. This for some people is good because they do not like accountability. The amount of work involved in manual testing and specially regression is why one should really look at test automation. I often see in projects that developers are behind writing least code possible. They spend good amount of time on that. But then they do not consider time required to fix the bugs.

If doing more in less code is sign of intelligence, then spending lesser amount of time on actual testing and regression is also sign of intelligence. Test automation saves you from that ordeal.

Next comes peace of mind. No one likes to spend extra hours in office. A good coverage through test automation gives you confidence that your code is working well.One simple rule for improving test coverage is to add a test case or test data in existing test as soon as you find a bug. This also helps in taking up requirement or design changes. When you change the code, the tests automatically tell you what is broken, so you can either tweek the tests to match the requirement change or fix the code where broken.

The reduced time to identify a bug and increasing resilience of your code is one more reason why you should do automation.

Most often seasoned developers loose their appetite to learn something different other than new improvements in the technologies they work on. In many IT service companies there are two career progression paths. One leading to higher technical roles and other into managing people. Those who believe that their natural progression is in management tend not to learn programming beyond a limit. I have even met folks who told me that they have been developers for 4-5 years now they don’t want to code and they will only review the code. My question is if you are so eager to get into management and learn about it, ready to give PMP exam for that, why not spend a little time on learning testing and implementing it on your code? You learn coding because you want to lead team of developers, will you not be leading testers as well?

Learning test automation will give you an edge even if you plan to go into management. If you are planning to get into higher technical roles it anyway is going to teach you how a good code looks like.

In scenarios like developing for desktop (Windows or Mac) or public facing web sites there is another challenge. When the product is going into hands of general public you are really not in control of what combination of OS version (Major, Service Packs), Browser, runtimes like JVM or .Net they are having. The combination of these you need to test your product on even after rationalization is quite large.

The problem of running and testing your code on all combinations of environments can only be solved by automation including UI automation.

I will stop here as I believe the major reasons here are covered. We will move to when in Part II of the series.

  • Riding the TDD/BDD process – Part II (coming soon)
  • Riding the TDD/BDD process – Part III (coming soon)