 The phases of TDD are the steps that we presented previously. Back refer them as the TDD mantra, red, green, refactor. You start with a red status where the test that you just implemented fails, then you must write the corresponding code for the feature to produce the functionality and make the test pass. This is how you achieve the green status. Finally, it is time to conduct some refactoring of the code while ensuring that the test still passes. This might imply going forward and backward from refactoring to updating the code and checking the test status. But at the end, this ensures that the new feature was accurately added. This loop will then start all over again with definition of a new test for a new functionality and the cycle repeats itself again. Another ending loop where programmers iterate their code over and over again, adding new code whenever they have a written test for it and making sure that the new code complies with the standards and best practices that the team has in place. TDD is what enables you to code and takes most steps when writing software, increasing the code base bit by bit. This is an example retrieved from James Shaw book and blog to guide you through the phases of TDD. So take for instance the following task. Create a Java class to parse an HTTP query string. Pretend you're in an alternate reality without a gazillion libraries that already do this. The first step is to imagine the features that you want to code. Then you have to consider, like for instance, a hash map might be useful and several features might be quite overwhelming. Unfortunately, this would take more than five lines to code. So we need to think of a smaller increment. Let's write the test. Remember, this is partially an exercise in interface design. We settled on query string as the name for the class. A query string shouldn't return a hash map. So it should encapsulate a hash map probably. It would provide a method such as a value for name to access the name value pairs. But thinking all of this and about the task forces us to figure out how we want to design the code. Building that test seemed like it would require too much code for one increment. So the choice was to have this test to drive the creation of account method instead. We implemented account method that would return the total number of name slash value pairs. The first check test here presented would check if I have only one name value pair available. This code, as it is, will not compile because we don't have a query string implemented yet. So in order to do this, we implemented an empty query string class and a do nothing count method. This is enough for the red stage. To make this test pass, the right answer is artcoded. So we will be implementing the method and we will ensure that where we once had a return zero inside a public int count, we now have a return one. Would it count the number of equals signs? It probably should. Would it be more complex that the implementation here provided that is artcoded? Probably. But not all query strings have equal signs. We didn't commit to any particular course of action in advance. It remained open while we discovered new approaches. This was enough for the test to pass. And finally, it's time to refactor. So query string is not a good name. HTTP query is the adequate name and thus an overall rename was conducted. Next, we wanted to get rid of that artcoded return one, but didn't want to have to deal with multiple query strings yet. So testing an empty string would require improving the code in count without making future increments too difficult. A new test is written and the result would be, as expected, a red bar because we haven't updated anything in the class yet. So this establish the minimum required for the red stage. What was or what will be the fastest way for us to get back on the green bar once again? We decided to, in the class, check if the query string was blank. And if the query string was black, we would return zero. Otherwise, we would return one. And this is enough to put the test on the green bar once again. Refactor. Well, this time we decided to start cleaning up the code of the tests. QS was the name of the variable used in the tests. And we considered it an inappropriate name. So we updated it to query. It was time to do the cycle again. We needed to test the case when the query string is new. This test forced us to think about what behavior we wanted when the value was new. As fans of code that fails fast, we decided that the new value was illegal. This meant that whenever a new value was detected, an exception telling colors not to use new values would be thrown. So this is the actual implementation of our test for a query that is new. As you can see, we would fail and we will show a throw exception and we will also catch the new pointer exception in the test. How will we be able to make, because this is a set of for the red bar, what changes do we need to put in the class for us to get a green bar? Actually, it is a piece of cake. We added this condition if query equals new and we throw a new pointer exception. And this was enough to comply with the previous method of tests and establish and obtain a green bar. The most important aspect in the refactor phase is to always stop and seriously consider whether the design needs refactoring and this includes the tests also. If the production code and the tests look okay, there isn't anything significant to change. No refactoring should be in place and we will keep it our code like this. Okay, now what? These tests were done. It's time to implement the value for method. It was one of the first methods that we have considered to implement our class. Given the name of a name value pair in the query string, this method would return the associated value. To make the tests fail, we added a new aversion to the end of an existing test method, the test one name value pair test. So as you can see, we added an a30 equals that checks if value is the return value for the value for method that needs to be implemented. Once again, this was a red bar. To make it green once again and fast, we implemented this in the HTTP query class. So the new value for form method implements a split in the query and returns the second position in the returned array after the split. The code implemented passed the tests, but we know it was incomplete. What if there were more than one equal sign? Or if there wasn't any equal signs, we need proper error handling. We made a note to add tests for these scenarios. When considering the refactor, we added another assert for one of the value pair tests. This assertion would make the test more complete without adding further tests.