QA Friday 2015-Dec-25

How do you test changes in a large project? This question was asked during a recent live weekend class by Rushton W. In the class, I was explaining the benefits of compiling and testing changes often and Rushton wanted to know how this worked in a large application like might be found in a major software company. This episode explains three activities you can take to help you test your changes. The first is to make use of automated tests including unit tests. One of the first unit tests that I always write when working on a new class is just a test that makes sure that the class can be constructed. The second is to make sure to involve the customer. This can really be whoever is going to use your program. Use feedback from the customer to help you write more tests. The third activity is to adopt a design that will allow you to test your changes without needing to build everything and perform a full application install. You want to have small components that are easier to test with unit tests but also easy to just build that one component and swap it into your application for more integrated testing. Listen to the full episode or read the full transcript below. Transcript There are many ways to go about this and you shouldn’t take this explanation to be the only way. What I explain here has worked well for me. Let’s say that you’re just getting started on a new project. There’s a concept called the minimum viable product, or MVP, that you’ll want to focus on first. That’s a really good topic for another episode. I’m going to keep this episode focused on answering the question about the best way to test your changes. You’re not going to be working on the MVP directly because something like that is usually too big. It can also be intimidating to think about an MVP as a whole. There are software patterns that can help you identify solid designs that have been proven through countless projects. I’ll go over various patterns in other episodes. Let’s say for now that you need to be able to read a text file and follow some instructions contained in that file. You’ll want a class that knows how to read the file and return other objects that represent the actions you need to take. This is a good tangible place to start and will give you a result that can be demonstrated when you’re done. Now that you have a place to start, follow these activities to make sure that you can test your changes. The times when I’ve been on projects that struggled, were usually because we weren’t doing one or more of these three main activities. The first activity is making sure you have automated tests. This includes unit tests. Ideally, you’ll have a dedicated quality assurance or QA team that can write code just like the development team. It really helps if you write a new unit test first before writing any code in your project. In this example, the first unit test that I’d write would just make sure that my new class to read a file can be constructed. Let’s call this class fileParser because it works with files and parsing just means reading and understanding the contents of something. You write the test before you even create the fileParser class. Why would you do this? Why write code that won’t even compile? Well, we’ll fix the compilation problem in just a moment. But the reason to write the test first is so that you can take on the role of a consumer of your class. You can write code that constructs an instance of your fileParser in a natural way. I’ve seen it happen too many times where I’ve jumped in and written a class only to later find it clunky and hard to use. It seemed perfectly reasonable when I was writing the class. Once you write the construction test, then create the class and add just that one constructor. Then build and run your tests. Keep doing this. Write a test, write the code to get it to compile, and write