Test Driven Development is... everything. Before we get into specifics, let's consider some advantages of TDD. One major pro is that TDD allows us to easily update software to include new business rules. This directly impacts scalability. Additionally, debugging becomes less painful; we are forced to think critically about what we want our code to actually do; TDD makes us simplify our code, resulting in a quality, clean, maintainable code base.
So how is TDD done? There is an idea called Red Green Refactor. "Red" means that we create our test to fail. I like to go ahead and set up my dependencies, implementation method signatures returning null and any method level documentation. Now we write the tests. I'm a fan of JUnit and Mockito for Java and Mocha for Javascript. When you write tests, consider carefully what you want the code to do and account for negative scenarios like bad user input and empty data sets. Naturally, the tests will fail because we return null in implementation. Next, we minimally fill in our implementation code just enough to get the tests to pass. Now that we have red and green, it's time to consider how our code is behaving and can we optimize. You guessed it! Refactor time. A few questions to ask yourself here might be: Are my tests isolated? Can I reduce duplicate code in either test suite or implementation code? Do I have negative tests?
Good test driven development practices will strengthen the foundation of any application or service and allow for scalability. To further understand TDD consider the following topics: AAA(arrange, act, assert), Unit tests, Integration tests, System tests, Performance tests, User acceptance tests, Black box testing.
So how is TDD done? There is an idea called Red Green Refactor. "Red" means that we create our test to fail. I like to go ahead and set up my dependencies, implementation method signatures returning null and any method level documentation. Now we write the tests. I'm a fan of JUnit and Mockito for Java and Mocha for Javascript. When you write tests, consider carefully what you want the code to do and account for negative scenarios like bad user input and empty data sets. Naturally, the tests will fail because we return null in implementation. Next, we minimally fill in our implementation code just enough to get the tests to pass. Now that we have red and green, it's time to consider how our code is behaving and can we optimize. You guessed it! Refactor time. A few questions to ask yourself here might be: Are my tests isolated? Can I reduce duplicate code in either test suite or implementation code? Do I have negative tests?
Good test driven development practices will strengthen the foundation of any application or service and allow for scalability. To further understand TDD consider the following topics: AAA(arrange, act, assert), Unit tests, Integration tests, System tests, Performance tests, User acceptance tests, Black box testing.
Comments
Post a Comment