Unit Testing

It ain't that hard...

Remember, Unit Test should follow a pattern resembling Arrange, Act, then Assert. Follow the guidance below, and it will come together.

1. You are coding the test before the solution is coded.

2. You may not know what the interface is before you start building the test. However, once you have the arrangement done, you should have a clear understanding of the interface.

3. Don’t code the test after you have already coded the solution. The test is to prove your solution, not to validate your assumption about the solution.

4. Get consumers of your interface involved in defining the success of the test. This also includes your Test team, also known as a QA team.

5. Once you have completed steps 3 and 4, you will have the code for your Act section of the unit tests.

6. Coding your assertions is simple. What does a pass look like? Can nulls be a pass? Are you rejecting bad data, good data, or all data? The code you will be testing is a wall of a dam. You want to make sure that there are no holes. Opt for cases that approach the edge case boundaries.

7. If the data functionality can cause critical data or operation loss, then push that edge case boundary harder. That is where hackers are looking for holes. But they are also looking for holes in the easy spots in the middle, too.

8. Your Assertion is generating some result data. Ensure that the result data is precisely what you expect. Fail unplanned results, so you can review and determine why they occurred.

9. Below are new guidelines from me to reflect the changing of the times.

   1. Have AI write the test with your assistance, or your code, after you have written the tests. Don’t have the AI do both. For the same reason we don’t have engineers review their code, we also don’t want AIs to write tests and production code. One or the other.

   2. If you prefer to embed test code into your release builds, consider using conditional builds to prevent shipping your test code with your library. This is most important if your code could get into the hands of a hacker.

   3. Obfuscate your code. If there is any chance that hackers could obtain your code, it is better to use obfuscated or IL-only code, making it that much harder to reverse engineer or hack your system.

   4. Use the test framework to perform behavior testing, validating that you have hardened your coded endpoints as much as possible. Validating in- and out-of-data is critical.

10. These are bonus bits of wisdom. Typically, it would have been covered in another post.

    1. SAST (Static Analysis Software Tool) and DAST (Dynamic Analysis Software Tool) are a must-have for all commercial software and most internal software. It’s all about risk analysis. Do you know if your software is vulnerable to hackers? Will they be able to hack your Database? Will they be able to steal confidential data? Are they going to be able to cause you to be sued for millions of dollars?

    2. Besides Veracode, Perforce, and Snyk (three of my favorites, among many), there are many high-quality SAST and DAST vendors available. Explore and discover which ones best suit you.

If you have any questions, let’s discuss them.