In the last article, a simple solution to the common FizzBuzz software developer interview screening test was discussed. For the majority of employers, the simple solution provided will likely be acceptable as it will be very similar to the other submissions received. However, don't you want to be a little bit different in the interview process? Besides, there's a healthy percentage of developer teams that insist on TDD, and if you try to join one of those teams by submitting non-testable code during the interview process, then you are going to be at a competitive disadvantage.
Introducing the first Unit Tests
I ran across a definition of Legacy Code somewhere and it has stuck with me: Legacy Code is defined simply as code without tests. (And perhaps one of the most important properties of Legacy Code is that you typically resist making any changes for fear of breaking something.) You can assume that every time that you start to write the code first instead of the test first, you are extending your legacy codebase. Perhaps future blog articles will address some of the issues of an ever-growing legacy codebase, but we'll skip those long debates for the moment.
The solution provided in the last article was simply not easily testable. The responsibilities were intermixed as the game logic was intimately tied to the console output. The only way to test the results of our application is to parse the output displayed on the screen.
Unit Testing seems like a pretty straight-forward subject, but there are variations and nuances emphasized by different programming teams. For example, you may run into a Must-Mock team which insist on coding everything to an interface and mocking every aspect of your system during testing to enforce as much isolation as possible. You may also run into a team that uses DUnit only for building Integration Tests without a single test double in sight.
For this article, we'll take our previous application and extend it with DUnit to provide a simple test suite to validate the FizzBuzz output. First, we'll need to separate the console output from the value generation. (You should note that thinking about the tests first, or even better by starting to write the tests up front, this desirable separation should have been obvious.) Let's create a new unit and move the game logic into it:
The loop is initially moved into the DPR during this refactor:
If you run this, you'll get the expected outcome if you manually inspect the console window. But now let's add some tests to automate this validation process.
Select the Project->Add New Project... menu option in the Delphi IDE (or right click the default ProjectGroup1 in the Project Explorer and select the same Add New Project... menu item.) You should be presented with a New Items dialog. Click on the Other->Unit Test category and ensure Test Project is selected and then select OK.
This should start the Test Project Wizard dialog. Let's use the defaults for now and simply click on the Finish button. You can then add a new unit to the project which we will use for our suite of tests. In the current scenario, we have a simple procedure to test so we'll create the test unit ourselves and not rely on the DUnit expert to generate the test suite unit.
Below is what the first test suite code might look like, and all the tests currently pass.
For a quick 5-10 minute code screening test, adding some unit tests like this to the FizzBuzz project could help distinguish you from the other applicants. (But if you started with the tests first you would not have to refactor later.) Let's not affix our 'Must-Mock' badges on our shirts just yet and over-engineer the solution, but let us see if we can quickly improve on the code above.
Creating a simple procedure is a common solution to many Delphi tasks. As we shown above, these simple procedures can certainly be testable - and if you are just going to get started with Unit Testing, this may be a valid first step. However, the DUnit tooling is built around testing classes, so you will inherit some minor benefits by simply switching to class based development.
Let's refactor the CalcFizzBuzz method into a class. This takes your code embedded into a single procedure and allows it to be more extensible in the future.
As you can see, it's nearly identical code to the original simple procedure but it's laid out in a way that makes it easier to work with. It seems pretty minor in this small bit of code, but sometimes small improvements go a long way.
This new class forces some minor changes to the DPR file to utilize this new class. Perhaps we could extract the loop into a GameSession in a future modification. And perhaps we could extract most of this code out of the DPR... it all depends on how much effort and time you have to apply to this task.
The test unit is updated as well:
Running the tests and seeing all green is good! We know we haven't screwed up the basic operation of our FizzBuzz solution.
If you were only given 5 to 10 minutes to whip out a FizzBuzz solution in a job interview, you will probably end up with a little time to refactor. As you can see above, it doesn't take much effort to change from a simple procedure to a class and this process helps to clean up some of the code and allow for easier modifications. And if you provide testable code up front, you are nearly guaranteed to be ahead of other applicants (besides helping to ensure that your little code test actually works as intended!) In addition, some employers may ask for small modifications to your FizzBuzz solution in order to see how quickly and easily you can handle change requests. For example, they may ask for all values divisble by 2 to return "Flop". If you have the test infrastructure already in place, it helps to avoid some silly mistakes when you are making quick changes in a potentially stressful situation like a job interview.
There's plenty more we can do with this silly FizzBuzz code. Perhaps more articles will be posted in the near future based on feedback.
You shouldn't mention unit testing in Delphi without a reference to DUnitX. This is currently the gold standard in unit testing within the Delphi community. It's available in the later versions of Delphi, or simply grab it from GitHub. It's simply much more powerful than the built in DUnit framework as it's built for Generics, Extended RTTI, attribute based testing and more.