Testing

We write code to test our code these are referred to as automated tests. This may sound like double-work but saves time and improves quality. With adequate test coverage on a project, we know instantly when something breaks. Test coverage allows us to refactor code with a high level of confidence, as we have tests that confirm the features and functionality what were passing before the code change. If the tests are passing when you are done with the refactoring then you should have working code.

Key Concepts

• Types of testing: There are many different ways to test software, but unit tests are typically the first consideration. These tests focus on a single function or class. When many classes or functions are tested together, this is known as integration testing. Another popular type of testing is behavior testing, which tests the application as a whole and can use special tooling to help automate these tests.
• Test coverage: Even a simple function will have branches (e.g. if statements), so multiple tests will be needed to make sure all code paths in a function are exercised. Test coverage is used to show how much of the code is being tested and which parts are not covered.
• Testing provides early warnings: Sometimes changes in one part of the application will accidently break other parts. With tests, these side effects are surfaced immediately and can be addressed in the same pull request. Without tests, the bugs are passed along and will be found at a much later time which can be costly and time consuming.
• Testing improves maintainability: Write tests not so much for yourself, but for the dozens of other developers that will read and maintain your code over many years. Oftentimes, a test acts as a secondary means of documentation - communicating the purpose of a block of code. If the maintainer cannot understand the original code, the tests exercising it may provide additional insight.

Pluribus Expectations

• Coverage: Code should have tests that cover at least 80-90% of your code base, with special attention given to key functions or modules. (Note: don't let the metrics drive your test writing - test what matters.)
• Quality: Tests should exercise high-value functionality and have meaningful assertion statements. Sloppy tests written only to get coverage metrics up are not helpful.
• Passing Tests: Code is not ready for review until all the tests are passing.
• Testing as a start: A great way to familiarize yourself with an existing project is to run the tests and add missing coverage. This will give you experience building, running and understanding the code while contributing to the overall health of the project.
• Test-driven Development (TDD): TDD is an encouraged but not mandated practice.

Resources

• TDD Overview Lunch & Learn