Developers who practice TDD use several frameworks and tools you may not yet be familiar with. But a more difficult hurdle to get over than learning new tools and frameworks may be changing how you think about and approach writing software. Writing a test before you write the code you are testing may not seem natural at first, so you may need to spend some time unlearning what you know about writing code.
The mantra of “red, green, refactor” defines the work flow for practicing TDD. Write your test first, even if it won't compile. Write just enough code to make that test pass. Don't worry if it's not pretty or you don't feel you've covered all the bases the business will care about; that's not your priority right now. Just worry about the requirement in front of you at this moment. If your tests meet the current business requirements and they pass, you're done. Once you have written enough code to complete the business functionality, refactor your code to make it readable and maintainable.
Remember that tests are part of your code base too. Your code will be only as good as your tests are. Don't just test the “happy path.” Make sure you triangulate your tests to expose weaknesses in your code. Treat your tests as if they were part of your business logic; do not let code rot set in.
Download the tic-tac-toe GameWinnerService example from this chapter and complete it. Come up with your own feature to define game rules. Write tests and then add to the GameWinnerService to ...