| How does TDD look like in real world development of microservices or web interfaces? That's what this series is all about. | |||
|---|---|---|---|
| 1. Introduction | 2. The requirements | 3. Test case analysis I | 4. Test case analysis II |
| Test case analysis III | 6. Test case analysis IV | 7. Setting up a project with Spring Boot | 8. Which tests to write? |
| 9. API design | |||
Most TDD examples start out with a calculator. Ours will start here as well. But we’re not going to write a test for “2+2”. No sir, we’re going to test drive the calculator display.
But what does it actually do?
We’re going to create a simple calculator as a web app. We’re going to concentrate on the backend (although we might get to the other end in the future). It’s going to use REST APIs to access a backend where all the logic will be. While regulator calculators focus on what happens when we press “=”, for us the main focus is what happens on the screen as we press the keys. There’s some logic in there as well.
We’re already making a couple of technical decisions – we’re using Java, Spring (and I’ll use Spring Boot for creating the main project), we’ll be using REST for the delivery protocol. Also, everything interesting is done at the backend. The UI is just displaying the results of the backend calculations.
We’ve skipped over any discussion about whether any of these decisions is the right one. In the real world, we’ll have lots of meetings around them. Plus, look at who are the competitors for our app and its value, and consider whether to build it, or what makes it special. But we’re above that.
For our purposes these architecture decisions are not negotiable. Within these constraints, we’ll do what we can.
Ok, let’s look at the requirements:
- The calculator has a display area, which is updated as the keys are pressed.
- The calculator has a keypad with digits (0-9), operations (+,-,*,/), a C clear button and an ‘=‘ button to execute the calculation.
- Any other key pressed doesn’t affect the display.
- When the calculator starts it displays “0”.
- Pressing any digit, the display adds that digit to existing display. The exception is ‘0’ which is presented only if a number different than ‘0’ wasn’t already pressed.
- Pressing an operation key does not change the display.
- Pressing “C” resets the calculator.
- Pressing “=” shows the calculation result. There are no intermittent results shown until it is pressed.
You know, something like this:
By the way, this is not one of the fancy calculators that shows you interim results even before you press “=”. Only a press on “=” shows the result. I am going to add another requirement to make it interesting (as if it wasn’t already).
- The input and output to the logic at the backend are strings.
I know, we’re going to corner the market with this one.
Now most people at this point do the following:
- Say they understand the requirements
- Create an empty Spring Boot project in Eclipse
- Code very fast
But we’re not most people. We’re going to wait on that, until we actually understand the application in terms of test cases. Because that’s how we roll.
PS: That’s really how we roll. Not just in examples.
Even in “regular” TDD, we do some test planning. We don’t just rush over and write the first test.
Understanding the test cases allows us to clear things up, understand the requirement better and ask questions from our majestic product manager (that’s me also). Even negotiate the requirement if we’re crafty enough.
That’s the next step. Requirement analysis through test cases. If if you think that’s simple, you maybe surprised.
0 Comments