Prototypes

You may consider not doing TDD with prototypes. By prototype, I mean an app that will most probably be thrown away or completely changed very soon. It may be created when you are experimenting with some technology/framework or are just asked to conduct research on something.

TDD gives you a high code/flow coverage, which may need to be changed in case of prototype projects. If you are in such situation, consider resigning from TDD at this stage.

Short living apps

Similarly to prototypes, short living solutions might be the ones where TDD is not the best fit. It applies to one-time-use apps or scripts which are supposed to do one thing well and quickly.

Short living apps are the ones where you may consider not using Test Driven Development. I’d even argue whether you need any kind of tests for such programs. Testing such apps or even scripts may be art for art’s sake. If something is supposed to realize a given task without fireworks (like reusability, maintenance etc.), I wouldn’t bother with testing it. It’s better to focus on solving your current, short-lived problem than on practicing the profound TDD idea ?

Unclear requirements

One of the reasons not to use TDD might be unclear requirements. The idea of writing tests in Test Driven Development is to define the expected outcomes for predefined incomes. As we said in the previous article, Test Driven Development can help spot the edge cases and make the business requirements more close to the code. However, if you don’t have these requirements defined, TDD might be a waste of time (at this stage). If the requirements actually arrive or are completely changed, your significant set of tests will need to be changed or even removed.

MVP

If you’re creating an MVP, with very short time and budget, TDD might not be worth the struggle. It’s probably better to resign from using TDD in that case. You should rather focus on your product and the business value it needs to deliver. TDD might slow down the delivery time, which, in case of MVPs, can be critical. It’s better to deliver the minimum viable product without TDD than to not deliver it with TDD ?

However, remember to add some tests, even post-factum. MVPs have a high chance of survival, so you’d want your final product to be tested and testable. You need to find a good balance here, not to make your solution completely untestable when it’s ready for production use.

Tests writing beginner

If you are a total beginner in writing tests in general, Test Driven Development might not be the best approach to start with. You may consider not to use TDD at the beginning of your testing journey.

To make Test Driven Development effective, you should be able to write tests quickly and efficiently. Starting to learn software testing with Test Driven Development may make you feel overwhelmed and discouraged. If you’re a beginner, I suggest to first write some unit tests, get familiar with that and then try to learn Test Driven Development.

It would be great if you can find some smaller and well-defined task to start with TDD. If you don’t have such tasks, try solving one of the programming katas (e.g. this one) with TDD.

When not to use TDD – summary

Like everything, TDD is not a gold standard for every possible case. It should be used as often as possible, but not always. Remember to always weight the gains and losses from using Test Driven Development in a given project or application at a given time.

What’s your experience with Test Driven Development? Can you list any more cases where it’s not worth using it? Share your thoughts in the comments below!

The post When Not To Use TDD? appeared first on Yumasoft.

Moving design into code

With test driven development, you create your tests before writing production code*.

Having that in mind, one of the benefits of using TDD is that you need to move your design requirements into code before you even write a single line of business logic.

It means that you need to spend time thinking about good names for your tests. I often create empty tests straightaway after staring to work on a task. Spending time to create well-named test methods can help you quickly spot missing parts in the design.

*By production code I mean the actual business logic except the tests’ code. This is only to differentiate here, but I personally consider my tests part of the production code in real life. Tests are as important as all the code.

Finding edge cases

Going further, if you create many empty tests with well-thought names, you will surely find many edge cases. Thanks to test driven development, you’ll verify the business requirements by your code without writing even a single line of it. Discovering edge cases and boundary conditions will let you clarify the requirements or even change/adjust them before any production code is written ?

Structuring your code beforehand

You’ll see that TDD forces you to think about the code you’re about to write beforehand. You’re going to think about production code to-be-written: how and where to add it, what methods, parameters and classes are needed. Thanks to that, you can quickly notice that maybe the place you’d normally place the new code in is not the best choice. Maybe it requires too much changing instead of modifying.

Such approach leads to taking and rethinking architectural and structural decisions before writing a single line of production code. In the end, it saves you a lot of time. Without TDD, you’d probably just add this new code where you thought it’s appropriate and struggle to refactor it later. And refactoring without tests is dangerous ?

Allowing to refactor

Test driven development is based on red-green-refactor cycle. As soon as your test is green, you can safely (for sure much more safely than without tests, especially if you combine TDD with mutation testing) refactor the code you’ve just written.

In the end, the quality of your code is much higher than it would be without tests. You don’t feel the fear of refactoring, which is a common blocker for improving code quality in legacy systems.

Making implementation very easy

When you move from red to green phases of TDD, it’s time for implementation. From my experience, writing production code that satisfies TDD-produced tests is very easy.

I find it much easier than writing code not covered by TDD-based tests. You exactly know what to do and which tests must pass. Thanks to that, your implementation is minimal – it should only make the test(s) green.

Creating current code documentation

Implementing a new feature with test driven development will leave you with a comprehensive set of tests. From my experience, I write few times more tests with TDD than in a “traditional” tests-after-code mode.

As a nice side effect, you’re building and growing the only possible, current documentation of your code – set of your tests. Only tests can tell you the truth about your code. It can’t be achieved with any other kind of documentation. Notice one more advantage – you’re creating documentation… without writing any documentation! ?

Current, well-named tests are very helpful not only for developers, but also for the so-called business people.

Spotting architectural problems

Last but not least, test driven development helps to solve application’s architectural problems. Tests should be relatively easy to write. If the test is hard to write before production code exists, it might mean that the architecture of your solution is wrong. There’s a problem somewhere that should be addressed.

That’s why it’s very important to start working with TDD as early as possible in your project. There might be some cases where TDD it not suitable (maybe I’ll write a separate article about it ?), but in quite mature and stable projects, it should be a gold standard. Altering the architecture is much easier early in the project.

The post 7 Reasons To Start Doing Test Driven Development appeared first on Yumasoft.