Transcripted Summary
In Chapter 1, I'm going to be introducing the concepts behind Acceptance Test-Driven Development for Front End. So hopefully, you'll have a better idea of when we add in the frameworks and the testing, how to go about doing that and why you're doing that.
Kent Beck has a great description of what TDD describes.
"First, you should write new business code only when an automated test has failed. Second, you should eliminate any duplication that you find."
So that was when you would do your refactoring. But first, you should have that failing test to verify that the code that you're going to write works as you expected it to.
It's easy when you're writing code to get lost and start refactoring as you're going along, build out big chunky features or build in logic which you didn't necessarily need.
This is the cleanest way to effectively achieve the goal.
The TDD cycle is this loop where you write the failing test, you make the test green, and then you go back in, and you refactor any code.
Then what is acceptance test-driven development?
So here, you're writing a single acceptance test and then just enough production code to fulfill that test.
You also need that TDD cycle.
You now write the failing acceptance test first.
Then you go into the TDD cycle, you make that green.
And then you run your acceptance tests again, and you make that green.
So, all of the cycles are green at this point.
And then, you can go in and refactor any part of the acceptance test, which may have changed with your knowledge of how you have implemented the feature. You may want to add in some scenarios, for example.
And at that point, again, you go through the loop. You may want to change some of the business logic at that point as well.
That's the ATD cycle — we have that loop around the TDD cycle.
So now you know the theory behind it.
Now you can apply it to the front end technologies and we can get into setting up your project and start implementing features.
