Test Driven Deployment

Hello dear readers. Now it is time to talk about Test Driven Deployment testing.Test driven development is a software development process that consist on the repetition of a very short development cycle. At first the developer writes an automated test case that defines an improvement or new function. After that, it produces the minimum amount of code to pass that test, and at the end refactors the new code to acceptable standards.

For test driven development the following steps are followed: 1. Add a test; 2. Run all tests and see if the new one fails; 3. Write some code; 4. Run tests; 5. Refactor code; 6. Repeat.

Test driven development is like a way to turn the code into an instruction manual. The goal of software tests is usually to catch any errors before making that software available. The first tests you write, are just like a roadmap for what the perfect version of the code is supposed to do. As this type of testing consist on the test written before the code for the program is written, you expect the tests to fail at first. It takes something that can be discouraging and turns it into a clear instruction for what to add next to the program.

Some of the benefits of TDD are efficiency, readability, etc. TDD just makes you a better programmer. It is said that most of the programmers don’t read the written documentation for a system, instead they prefer to work with the code. When trying to understand a class or operation most programmers will first look for sample code that already works with it.  Well-written unit tests do exactly the same and as a result unit tests effectively become a good portion of your technical documentation.
Let’s assume you add some new functional code, compile, and test it.  Chances are high that your tests will be broken by defects that are in the new code you just created. It is much easier to find, and then fix, those defects if you’ve written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps. I generally prefer to add a few new lines of functional code, typically less than ten, before I recompile and rerun my tests.

Please check out the following website for more info: https://medium.freecodecamp.org/test-driven-development-what-it-is-and-what-it-is-not-41fa6bca02a2. I found this website very useful in understanding TDD.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s