Tech debt: Flaky Tests and How to fix it

 Are getting Flaky test on your nerves? Here is how you can fix them easily.

 

Here, How to handle flaky tests. Start on top of the list and go down until the problem is fixed. 

1. If it's easy, then fix them.
2. Complain about it. 
3. Disable flaky tests.
4. Delete flaky tests.

Sound easy, yes it is. Now let me explain it.

1. If it's easy, then fix them. But is is in 99.9999% of the cases I seen, it not easy. So you have to try the next idea.
2. Complain about it. This is an underrated or over seen solution. If you complain about a flaky test you trigger maybe an other developer who knows an easy solution. 
3. Disable flaky tests. A flaky test doesn't secure any code behavior, because it's flaky. But it desensitise you, see image above. And a flaky test cost you development time, rerunning the tests. So there are only benefits in disabling them.  
4. Delete flaky tests. If you are ready to disable the flaky tests, you can delete them, because it's dead code. An additional benefit of deleting it, it makes it easier to refactor your code.

 If you you have any comments or other ideas, leave a comment below.

 

Dropping TDD, not - Part 1

 This article based on a Twitter discussion, this is Part one. An IT consultant came up with a slide of transformation, I guess. There are some interesting points on the slide and I don't know the real context but the first point was: dropping TDD. This triggers me and I jumped in a small conversation.

 

I like TDD, I use it for more the a decade. From my point of view TDD is a good practice in developing quality software, what ever quality this means.

So I was triggered and someone in the discussion send me a video link of Dave Thomas (https://youtu.be/a-BOSpxYJ9M?si=kcwuhVgyQoxmGLEL). The video is from 2015 it's amusing, most of the things are true, most things mentioned are over simplified, but that's for the audience, OK, anyway.

There was one point in the presentation about TDD. He (Dave Thomas) didn't use TDD and not writing tests. That's a big Huh, really. Yes, I assume, what he want to point out is that if your very experienced in TDD you can write TDD like code without a tests first. This works fine if you have the ideas of decoupling and separating of abstraction levels or concerns internalized deeply that you are capable to write TDD like code without the tests. I have to confess that I do it often in the same way. But that doesn't mean that I not writing tests anymore. I write test for following reasons:

1. To verify that complicated (eg. RegEx) or not intuitive code parts are working fine.
2. To clarify for other developers that this specific code behavior is important. 
3. To have a security net for refactoring.
   
4. Reverse engineering

Tests are still important and TDD is one really good approach for quality software. Don't drop TDD.

Test Driven Development (TDD) more then software tests

In the practice of software projects and software developers there are great misunderstandings about test-driven development (TDD). Most developers do not see or know the difference between JUnit testing and TDD. They believe that TDD is a theoretical, time-consuming testing approach.

 TDD is more then testing:

1. Proof that your code does the expected thing
   
2. Safety net for (your ongoing) refactorings
3. Helps you to separate concerns in your code
   
4. Last but IMHO most important, TDD is the spec of your code
   

PS: If you think you have to spend more time for the TDD, try it without.