A word about Test Driven Development
What is Test Driven Development (TDD)?
Test Driven Development is a coding methodology that consists of starting the development of a feature by writing a unit test for it, and only in a second stage actually coding its implementation. This is the reverse of a more standard approach where unit tests are redacted once the development of the feature is considered completed. The goal of this approach is to obtain cleaner interfaces, simpler design patterns and therefore modularised, flexible and extensible code. In this approach you transform your features' specifications into output expectations and progressively add to your code to meet the requirements set by the test. Instead of thinking about your feature abstractly, you think about your features' specifications and how it will be used by the end user or consumed by other parts of your application. It’s a “test first” approach which forces developers to be more rigorous and correct their mistakes instantly and consequently raise the overall code quality.
Test Driven Development is built around a 3 step process
1. Write a test (not THE test, careful. It’s not the full test yet)
Ensure that the test is failing, because the functionality is not yet implemented
2. Write just the code necessary to make the test pass
Ensure that the test passes
Repeat, adding new tests that complete the feature specification
You will iterate those 3 steps for any specification until your code is ready.
Tests are not the goal of TDD, but the means. The real objective is simpler and improved design patterns and high code quality.
What are the advantages?
This methodology forces you to plan your code in a very modularised way because tests for non-modular code are much harder to invent.
Every testable part of code needs to have a clear input, a clear output and a clear set of specifications of what it is supposed to do.
In other words, approaching one small chunk of code at a time means that you keep things simple even if your overall features' complexity is high. Simple means clearer interfaces and more robust code.
With TDD you have better code, not because of intense design thinking but because you handle your complex feature as the interaction of many small interconnected modules.
This test-ahead-of-code methodology leads to code quality through better design patterns. You will not miss on mistakes or edge cases issues very early on since all the possible scenarios will be taken into account in the test. We consistently observe better coverage and less time spent on debugging through this approach. This also ensures you don't skip testing any function. With TDD you stop “writing a function and checking if it passes the test” but instead you write the test and you know what kind of test your function is supposed to pass. For the lovers of a high coverage score, of course TDD is also a fantastic way to keep your coverage high.
Test Driven Development will help raise the overall quality of your code but it will also help your coding practice: working on one small chunk at a time will increase your capacity to focus and not miss out on anything. Developers can focus on making sure to meet each acceptance criteria and proceed towards focusing on refactoring. The refactoring will consequently be safer since you know test cases are already successful. You systematically get simpler code but well-tested code. The Test Driven Development approach also helps to have a comprehensive approach to bug fixing: instead of just trying to remove the bug you will have to understand the underlying reason for it.
On a higher level this methodology brings better code design and most of the time helps developers to be more thorough on building documentation. On the financial side, even though it’s more resource consuming, it arguably ultimately saves developers time by reducing the time they will spend fixing bugs.
If it is so good why isn't everyone using it?
More and more developers are turning toward Test Driven Development. Some might argue that TDD has a fixed cost of spending time writing your tests ahead instead of actual coding. This time consumption could be fatal for developers with a limited amount of time on their hands such as startup developers who need to code prototypes fast and have an MVP ready before running out of resources.
Test Driven Development is also not chosen over a more classic approach because of the time pressure and lack of understanding of the advantages of TDD from managers or clients or just because it is not prominent in developers’ training curriculum.
On the other hand, bigger companies usually have those resources and since quality of code is of the utmost importance in their coding standards they turn towards TDD.
Are Ponicode and TDD in opposition regarding unit testing?
You can think at first that Ponicode encourages a lazy approach towards unit testing by promising to generate them automatically through artificial intelligence. But it’s quite the opposite: Ponicode really puts the emphasis on unit-testing. It helps developers to focus on problematic outputs on their tests and to think of edge-case inputs to test their function with. Ponicode ensures that tests are made and that coverage is high. So Test Driven Development practitioners and Ponicode users really have the same test quality approach.
Will Ponicode become a perfect tool for TDD practitioners?
With Ponicode, developers using the Test Driven Development methodology are not (yet) getting the full benefits of our technology, it will help save time once the function is ready. Developers can get a Ponicode interface with a unit test table ready where they can manually put their inputs and outputs and test it quickly. They also can see if our AI makes input suggestions they didn’t think of.
Ponicode is a time saving tool for all coders no matter which coding methodology they choose thanks to quick automated unit test creation. Ponicode can really help boost TDD developers’ confidence since they strengthen the TDD approach with the AI suggestions. Even the most meticulous developers are human and forget to test edge cases sometimes; Ponicode can help identify missing inputs and avoid bugs early on at no cost.
We are providing some TDD friendly options for Ponicode such as building unit test tabs prior to function writing so you can manually enter your inputs and outputs before getting started with coding and check them later down the road (possible as long as the function prototype is defined). We are also trying to use documentation to know what the function is ahead of time.
The unfortunate reality is that a large number of developers sadly still do not use the TDD approach. This may be because they don’t believe in the method, or because they don’t believe they have the time to apply it.
This is where Ponicode comes in to help.
By making unit testing easier and therefore more approachable even to those who “don’t have time”, Ponicode has the power to demonstrate how much of an impact on code quality unit tests can have.
TDD or no TDD, Ponicode’s test suggestions, which target a multitude of scenarios and easily spot edge cases, can give that extra confidence in the robustness of one's code with zero extra effort.
Today, we join our forces with TDD promoters in saying that unit tests are key to beautiful code and we want to push the unit test practice as absolutely unavoidable. We are unit tests lovers and we believe in how crucial of a step it is for developers. We are unit test lovers, and we want to make it easier for others to love unit tests too.
Do you want to get started with Ponicode? We won’t discourage you. You can get started here.