This course shows how to use Test Driven Development (TDD) in a real-world setting. It moves beyond the discussing the basics of TDD; instead of focusing on the mechanics of TDD, this course uses TDD as a design tool. The course will cover unit testing both server- (node.js) and client-side (Angular) code. The goal of the course is to demonstrate how to use TDD to design a better code base.
Testing After In this final module, we're going to look at the opposite of what we've done so far, that is, testing afterwards. When someone takes the approach of writing tests after the code, there are three major issues they're going to have to deal with. The first one is what it's supposed to do versus what it is doing. When you write your tests before you write your code, you write a spec, and you're saying, here's what my code should do. My code should add two numbers, or my code should divide by a number. When you write your test after the code, all that you can really do is look at what the code is doing and then write the test. So now your code becomes the spec for your test instead of the other way around. This could cause problems; if your code has an error in it and you don't realize it before you write your test, all your test is going to do is ensure that that error is happening, it won't catch it and it won't prevent it in the future. The next issue that comes with writing a test after the code is verifying that the test even works. When you write your test first, the test fails, it's red, then you write some code and now the test passes. Nothing changed with the test, instead, something changed with the code. However, when you write your test after, nothing's going to change with the code, it's going to change with the test, and so once again we're getting into this issue where the code becomes the spec for our test instead of the other way around. The third and final issue with writing your test afterwards is the situation of how do I even test that? When you write your test first, you don't have a big block of code that you have to figure out how to test, you write a single test and you write a little amount of code to make that pass, and then you write your next test, and you repeat the process over and over and over again. But what happens when we write our code first is that we kind of get into this flow of just writing code, and suddenly our methods become big and sometimes complicated, and it becomes difficult to look and see how can I actually test what the code is doing? So I'm going to dig a little bit deeper into each of these issues.