Warning: file_get_contents(/home/u365-xgnvix6kximm/www/nukedbit.io/public_html/wp-content/plugins/jetpack/_inc/blocks/images/tiled-gallery_example-4-2c82eb59aaea53932f5e718e17284db71.jpg): failed to open stream: No such file or directory in /home/customer/www/nukedbit.io/public_html/wp-includes/init.php(265) : runtime-created function on line 1

Warning: gzinflate(): data error in /home/customer/www/nukedbit.io/public_html/wp-includes/init.php(265) : runtime-created function on line 1
Test Driven Development – NukedBit

Test Driven Development

Here at NukedBit we practice TDD whenever it makes sense, and on business apps where real money is made. Why? Because we don’t want our customers to lose money on trivial bugs that could be avoided by following a good development practice.

We have worked in this industry for more than a decade working as employee or as company owners, and in our experience in the end most issues can be prevented by just having automated tests running for you.

While there are many ways to test your app your app, for example you could just write unit tests without practicing TDD, or you could write integration tests, we found out that in most cases TDD is the best way to start writing new code.

Before delving into an explanation of the benefits deriving from TDD can bring to us . Let’s review its principles”.

These are the three rules we like the most:

– You are not allowed to write any production code unless it is to make a failing unit test pass.

Uncle Bob

– You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

Uncle Bob

– You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Uncle Bob

As we can see from the previous quotes, to get the best benefits of TDD we should’t write any production code without starting from the tests.

This practice has a few benefits:

  1. Each test can express a business requirement, or how it will take part in producing that requirement.
  2. The tests provide documentation for what we expect the code to do.
  3. Each time the tests are run your expectations will be checked.
  4. Refactoring code is safer.
  5. You are more confident that adding new features
    will safeguard existing features as expected and don’t break in production.

So does TDD remove bugs completely?

No it does not help have 100% bug free code base, developers are still human beings so if they forget to write a test case for an expected behavior, we can still get a run time bug. But when discovered we can still improve our test coverage so we are covered in the future.

TDD Make your code future proof

Being able to refactor your code or extend it will make us developers and companies more confident because we can go in production feeling safer. While sometimes it is also useful having Integration Tests, with TDD you can be confident that the expected business requirements that worked earlier will still work. But there is also another benefit, Clean Code, yes TDD help you write better code, and better code will mean it is easy to read and understand for others that will work on what we have written. Better code also mean you can easily extend it or replace it when needed, but of course TDD does not replace good Software Design or SOLID Principles, it just make it easier to apply them and keep them in check.

What all of this means for your business?

OK after all this tech talk what about our business what this mean for us?

A lot of software will send you what looks like a good offer, but in the end they count you’ll buy get a very costly yearly insurance plan, so they can cover bugs for you, or they just offer you a low hourly rate counting that you will be back asking for fixes and improvements very often. That’s not our way.

From us you’ll get:

  • Well you’ll get a lot fewer bug, and when you get one it can be fixed faster.
  • Fixing an existing issue should’t cause new unknown issues.
  • You can bring new features in production faster.
  • Fewer bugs mean less money spent after the software is released.