Lo-Fi C#: An Introduction to Coding

Source code examples from this chapter and associated videos are available on GitHub.

An important part of coding—​and a tremendously important part of the software development industry—​is testing our work to verify that it works as intended. This is somewhat separate from the topic of debugging, where we focus on tracking down and correcting issues once we know they are present.

Here, we want to talk about a structured approach to validating our code as we work.

For organizations that develop software, testing is not just a critical part of the development process, it can be a matter of staying in business. Users expect software to work, and they’ll move on to something else if it doesn’t.

In an organizated development environment, the core of a testing strategy is using automated tests to check that each part of the software works as intended. Developers use a testing framework—​a library of tools and methods—​to create and run unit tests. A unit test is a small piece of code that checks a specific part of the software. For example, in a video game there might be a method that adds points to the player’s score. Unit tests could be configured to automatically call the method with a variety of different values to make sure it totals the score correctly. With a few clicks, the developer can run all of the tests and vie a report of which tests passed and which failed.

A big advantage of automated testing is that it enables rigorous regression testing. Instead of just assuming that a block of code is good because we tested it when we wrote it, regression testing runs all the tests every time we make a change to the code. This way, we can catch problems that other parts of the program might cause—​like suddenly passing in a negative number to that score method.

We’re beginners here, so we won’t be using a testing framework or maintaining regression tests, but it’s important to have a sense of how things work in the job market.

We’re going to use a very simplified version of unit testing that we’ll call test cases. A test case is a set of inputs and the expected output.

You can look at test cases in two ways:

You can see my bias in those two options, of course, but that doesn’t mean it’s not true. Since we’re just writing out or test cases in our comment block, the person looking at your work (i.e., your professor) can’t tell if you used the test cases in a meaningful way or just tacked them on at the end.

Well, sometimes the professor can tell—​if you turn in code that has a clear mistake that could have been easily caught using our test cases strategy.

Anyway, here’s how we should be integrating testing into our development process:

Sample answers provided in the Liner Notes.