News

Q&A with Jason Bock: Testing Tips, Advice and Insights

Modern Apps Live! presenter Jason Bock explains the importance and value of testing.

• By Lafe Low
• November 14, 2016

The software development process can be complex, with many steps and requirements. One factor that should be never be absent from the process is software testing to ensure sufficient quality. And this isn't a one-time thing. It should start at the beginning and continue at every step along the way.

We caught up with veteran Live! 360 presenter Jason Bock recently to talk about what he'll be covering in his session "Coding for Quality and Maintainability" at Modern Apps Live! (part of Live! 360 2016 in Orlando, Florida) and some of his broader thoughts on ensuring software quality. Bock is an MVP (C#) and the Practice Lead for Magenic. Besides his regular Modern Apps session, he's also co-leading a post-conference workshop with Allen Conway, Brent Edwards and Kevin Ford entitled "Modern App Deep Dive: Xamarin, Responsive Web, UWP, CSLA .NET."

What tips do you have for getting the entire team to focus on quality -- not just QA?
The primary factor is time. Finding a bug or a painful interaction with an API when you're running tests locally on a developer's machine takes less time to resolve than it would if it was discovered in production. That's even quicker than having the QA team finding these issues (assuming a project has QA involved). You still need QA, but you can't leave it up to them to uncover bad parts of an application.
It's also about visibility. If you discover your code has a problem on your machine, then you can fix it and avoid some embarrassment. But if that bug makes it all the way into production, it can be disastrous. It can also erode trust between the users and the developers depending on how bad it is.

A lot of teams struggle with integrating testing throughout the entire development process. What do you recommend?
I look at it like a pyramid. You have a lot of unit tests running frequently because they're typically quick and isolated. Above that, you have integration tests that may take some time to set up to ensure all dependencies are accessible and initialized. A developer may run integration tests before committing, but they're not run as often. Finally, you have end-to-end or system tests run by QA. My definitions and scenarios will probably differ between developers, but generally I see this trend with teams committed to quality. This balance helps developers focus on testing their code and its interactions while still running tests for the entire application by people who didn't write the code.

You've probably seen a lot of "testing gone wrong." What is the number one thing you recommend teams DON'T do?
The biggest one is not writing tests in the first place. For teams that haven't written tests before, they sometimes don't treat test code like application code. Their tests end up being hundreds and hundreds of lines of code with no clear focus. As a result, those tests are hard to maintain, take a while to finish, and can be frustrating the developer team. They may even abandon their unit tests. Therefore, my advice for teams not familiar with writing unit tests is treat them with the same love and discipline they take with their application code. Subject them to code reviews and code analysis tools. Ensure they're designed well—that is, the tests methods should be small with a laser focus on what they're trying to test.

What's your number one tip for unit testing?
Use Arrange-Act-Assert, or AAA. This means that your tests should have three components (in this order):

• Arrange: Create test data or setup mock objects with their expectations
• Act: Create the objects and/or call the method you're trying to test
• Assert: Ensure the code under tests produced the right outputs and interactions

This keeps test methods focused and small. If a developer starts having too many "As" in their test, that means it's doing too much and it's best to break it up into multiple tests.

How strongly do you recommend automating the testing process?
I would strongly recommend automating test. Having tests automatically run after every build both on a developer's machine and after new code is committed in source control is a good thing.

For more on Live 360! events, go here.