English | 2015 | ISBN: 978-1-78398-742-9 | 284 Pages | PDF | 13 MB
Test-driven development (TDD) is a development approach that relies on a test-first procedure that emphasises writing a test before writing the necessary code, and then refactoring the code to optimize it.
The value of performing TDD with Java, one of the most established programming languages, is to improve the productivity of programmers, the maintainability and performance of code, and develop a deeper understanding of the language and how to employ it effectively.
Starting with the basics of TDD and reasons why its adoption is beneficial, this book will take you from the first steps of TDD with Java until you are confident enough to embrace the practice in your day-to-day routine.
You’ll be guided through setting up tools, frameworks, and the environment you need, and will dive right in to hands-on exercises with the goal of mastering one practice, tool, or framework at a time. You’ll learn about the Red-Green-Refactor procedure, how to write unit tests, and how to use them as executable documentation.
With this book you’ll also discover how to design simple and easily maintainable code, work with mocks, utilise behaviour-driven development, refactor old legacy code, and release a half-finished feature to production with feature toggles.
You will finish this book with a deep understanding of the test-driven development methodology and the confidence to apply it to application programming with Java.
What You Will Learn
- Explore the tools and frameworks required for effective TDD development
- Perform the Red-Green-Refactor process efficiently, the pillar around which all other TDD procedures are based
- Master effective unit testing in isolation from the rest of your code
- Design simple and easily maintainable codes by implementing different techniques
- Use mocking frameworks and techniques to easily write and quickly execute tests
- Develop an application to implement behaviour-driven development in conjunction with unit testing
- Enable and disable features using Feature Toggles
Unit testing with TDD
What is the difference in the way we write unit tests in the context of TDD? The major differentiator is in when. While traditionally unit tests are written after the
implementation code is done, in TDD we write tests before—the order of things is inverted. Without TDD, the purpose of unit tests is to validate an existing code. TDD
teaches us that unit tests should drive our development and design. They should defie the behavior of the smallest possible unit. They are micro requirements pending to be developed. A test tells you what to do next and when you’re done doing it. Depending on the type of tests (unit, functional, integration, and so on), the scope of what should be done next differs. In the case of TDD with unit tests, this scope is the smallest possible, meaning a method or, more often, a part of it. Moreover, with TDD driven with unit tests, we are forced to comply to some design principles such as KISS (keep it simple stupid). By writing simple tests with a very small scope, the implementation of those tests tends to be simple as well. By forcing tests not to use external dependencies, we are forcing the implementation code to have separation of concerns well designed. There are many other examples of how TDD helps us to write better code. Those same benefis cannot be accomplished with unit testing alone. Without TDD, unit tests are forced to work with an existing code and have no inflence on the design.
To summarize, the main goal of unit testing without TDD is the validation of the existing code. Unit testing written in advance using test-driven development procedure has the main objective specifiation and design with validation being a side product. This side product is often of a higher quality than when tests are written after the implementation.
TDD forces us to think through our requirements and design, write clean code that works, create executable requirements, and refactor safely and often. On top of all that, we end up with high test code coverage that is used to regression test all our code whenever some change is introduced. Unit testing without TDD gives us only tests and, often, with doubtful quality.