From the course: PHP: Testing Legacy Applications

TDD vs. test after

From the course: PHP: Testing Legacy Applications

Start my 1-month free trial

TDD vs. test after

- [Instructor] I have told countless people before that test driven development is really a design pattern. You are using the test you write to guide you as you build your interfaces and your APIs. Code written using TDD tends to start to look the same, large number of objects with a few methods, accepting input, transforming that input and then returning that output for use by something else. When in many cases you already have code written and it was not designed with test in mind. Despite the uphill climb you want to add test to give you and others some confidence that the next time they change some code everything is not going to figuratively explode. This is often referred to as test after and requires a completely different skill set and I want to explain why. Test driven development assumes that you have already decided how you want your code to look like. Your tests are written as if everything is perfect and you just keep writing code until the test passes. You repeat this process until all your code is perfect and all your tests pass. Of course this is nonsense, when I'm doing TDD I am often exploring how things work before I commit to writing all the tests. I will write out what I'm trying to do as pseudo code, meaning free form English that states what I'm trying to do, and then I start turning the pseudo code into actual code line by line. I then repeat this process until I am happy with the amount of tests I have. Test after is totally different because you already have code that is being used and hopefully working in production. The test will look different because the design decisions were already made. Like I mentioned before, the secret power of TDD is that it forces you to consider things up front before you commit to a specific approach. With test after you're already committed to a specific structure and approach. That's not to say you can't go back later on and refactor or even rewrite the code, but work very hard to resist changing too many things at once. The real goal is to get some tests in place so they can tell you if you have accidentally broken something later on.

Contents