Would you like to have more confidence developing new code, verifying the behavior of your new code faster, and running through many different scenarios at the push of a button? What if you could make changes and not worry about breaking existing behavior, and decrease the number of problems with code? Are you curious about unit testing but never had the chance to try it out? Or, have you had a bad experience with unit testing in the past? In this course, I'll teach you how to have confidence in changing existing code and developing new code through a variety of techniques that center around effective automated testing. You'll learn by following along with a real problem, with real constraints.
Wes Higbee is passionate about helping companies achieve remarkable results with technology and software. He’s had extensive experience developing software and working with teams to improve how software is developed to meet business objectives. Wes launched Full City Tech to leverage his expertise to help companies delight customers.
Using a Testing Framework In the last module we saw how a console application can help us verify and run through a variety of scenarios so we don't have to manually punch those scenarios into our website every time we make a change to our application. But as we saw, there's quite a bit of code involved in that. Thankfully as we continue on our journey, things are only going to get better because we can leverage testing frameworks so that we don't have to reinvent the wheel every time we want to create verifications for our applications. As we'll see in this module, we'll refactor our test to use a testing framework and unit to reduce the amount of code and to allow us to quickly add new scenarios and only continue to build the confidence we have in our application.
It Just Works - Writing the Test First Our poor application has been suffering at this point. We can't do much with it yet and that's because we've simply been learning how we can go from the old debug style into a console verification application and then finally we just saw how we can make our life really simple by leveraging a testing framework. We can use all of that to help us verify all the scenarios we're going to have so we don't have to punch them in by hand. But now it's time to do something with that application. As we travel along our journey, something rather interesting happens. Perhaps you've heard of people referring to test driven development. In fact, that's kind of where I got the idea for the first module, debug driven development, or perhaps you've heard of test first development. All of this is referring to something that's rather simple. Thus far we've been writing our test scenarios after we wrote our actual code. Testing first is just the idea of flipping that around. What if we write the test code first and then we write the actual code after? Let's see what happens when we do that by updating our application to support due dates for any month, not just May, which is all we support right now.
Confidence in Complexity with Tests First I hope testing first in the last module wasn't too scary. I think it's a rather simple paradigm once we're comfortable writing some code to test our code. Now let's turn to the next part of our journey and there's a couple of destinations here. We're going to take all the skills we've built up thus far in the course and we're going to apply them to a bunch of different scenarios where we change our application to handle some edge cases and deal with bugs that users might report, to add new features, and enhancements to our application.