Skip to main content

TDD || !TDD

A few days ago, one of my colleague wrote a really interesting blog about TDD. He has explained benefits of using it,  and he introduced some lacks when you are using TDD, and he provided a really nice example how to use TDD. So this blog post is my reaction on it.

During software development in any normal situation, every normal person will encourage you to write Unit test, acc test and etc..

But TDD is methodology which will give you, as a software developer, confident that you know that your classes do what they suppose to do. It is normal that you get bugs even you are using TDD. TDD will not release you of bugs but it will reduce a number bugs.

Start with the first problem "DEADLINES".


DEADLINES,DEADLINES,DEADLINES !!!!!

In a softwrer development you alwayes have a deadlines, a deadlines make most of us nervous. And it is quite normal, every normal person will be worried does he or they as team can accomplish something untill deadlines. So you will be nervous at beginning of some process, you are not sure can you implement everything, you are asking yourself why i have accepted all of this tasks, will something go wrong. And tomorrow, when you start with work, and when you wrote a few lines of code, the situation is slowly changing, and you became calmer. But as the dedline in coming up, again you are becoming nervous. The fear is the first reason why you as software devloper rejecting to use TDD. 

So here is example how deadlines affect on the software developer:

The most of people first will create implementation (deadline comming soon i don't have a time for writing Unit tests first, you must be insane ...), but at end developer will create a unit tests, on so called working code.

Here i said: "on so called working code" because, you are not really sure what your code actually do. Actually you have idea how it is suppose to work and that some cases are working, but you can not be totally sure.

Problem is not in DEADLINES problem is in our side!!!

Real problem is how the unit test are writen, what was the purpose behind writing of unit tests.

Deadlines are namking us to write unit test because of code coverage not because of implementation. Developer do not like to be criticized by the team leader or other team members.

What are differences between TDD && !TDD

So in this two cases (with and without TDD) the purpose of unit test is different. 

TDD:

  • With TDD you really test your implementation, because implementation is product of your tests, in second case you are just focused to check did you covered all if statements, every loop, so that your class looks nice in Sonar.
  • When you are using TDD you are sure in yourself, at any moment you can change the code, because you have a tests which will tell you if you are on the right track.
  • When you are using TDD, bugs will not disappear, but the number of bug will be reduced, and the whole time for solving possible bugs is reduced.
  • You can easily add new functionality
  • Your code is clean, and can be easily refactored 
!TDD:
  • You have unit test which covers class implementation, but it is just covering it, it does not do a real testing of it.
  • In most cases the method which is tested is huge (more then 20 lines of code), depending on the level of complexity.
  • In many cases you are not comfortable with method implementation, you are afraid to refactor it or change anythings.
  • Changing of method implementation (not in functional way), causing changing of your tests
  • Tests are changed almost every time when method implementation is changed. 

Writing useful tests

When you are using TDD, you are creating tests for implementation,  so that means that you should be focused on the result, not on that how it will be implemented.

You should start with simple test. I have A and B and the method should return C. And then implement it, and so one like Bruno has already explained in his post (Test, Implement, Refactor).  

So what to do, when i need to include new technologies, i am starting with usage of new library in project, what then?

Same like usually, to test something you should have some expectations, and you  should create test as usually. So you will creat bunch of simple tests which will lead you to the right solution.

Many developers will say, i need to learn new technology i don't have a time for TDD crap. But including new library should not change anything. You will need a time to learn new stuff, but that does not have anything with TDD, it is learning process. 

When you are implementing something new with some new technologies, that should not change your's expectations regarding the results. 
When you writing test you simple prepare test data, run the method which is tested and check the results. So that means the concrete implementation should only satisfy your expectation, no matter what have you use in method to implement it.

Conclusion

In my opinion when you are practicing TDD you just can get benefits from it. And at end if you are writing Unit test for your implementation, then you should do it in the right way. 
Unit tests are not there just to make better code coverage, they are here to help you, to protect you from bad situation, to warn you when you doing something wrong.

Comments

Popular posts from this blog

Checking file's "magic numbers"

Few days ago I had very interesting task. Our customer required that we perform checking of so called file's "magic numbers" to determinate does uploaded file correspond to it's extension.  We are already allowed only to upload files with some predefined extensions (PDF, DOC ...). But this can not prevent some evil user to update an exe file after renaming it to PDF or DOC. So first of all I will explain what are "magic numbers", and then I will show how we handle them.

Simple Workflow Engine With Spring

Few months ago, during working on one of the company project, we had need to developed  REST services which is used for sending an email depending on data sent by client application. During developing this service we decide to create simple workflow engine which will be charged for sending an email, but also this engine can be used for any kind of simple flows. In this article i will explain step by step how you can implement your simple workflow engine which can handle sequence flow.

Running Spring Boot Web App on the Random Port from Port Range

By default the spring boot web application is listening on the port 8080 for the incoming connection. This behavior can be changed by providing server.port property value during starting of the application or as part of the application.properties or through the code by implementing EmbeddedServletContainerCustomizer. But it would be even better if we could specified a range of the ports which can be used for the starting the application. It would be great if I could specify a property like server.portRange=8100..8200 to define a list of the port on which I want to start my service. In this blog post I will describe how this can be done.