Testing
There are two main types of tests we run on the Conifer codebase: unit tests and integration tests. Both types tests are performed with PHPUnit. The difference is just a --group ... option passed to PHPUnit when it is run. Conifer uses Lando as its official dev environment, you can leverage both testing tools without having to install them directly on your machine:
sh
lando unit
lando integrationOr run them all at once:
sh
lando testThe Lando environment comes with built-in code-sniffing, courtesy of phpcs:
sh
lando sniffAs of 1.0, static analysis by PHPStan is also available:
sh
lando analyzeWriting new tests
Our guidelines for how and what to test are:
- One unit test case class/file per library class. For example, a new
lib/Conifer/MyNewFeature.phpclass file should be accompanied by atest/cases/MyNewFeatureTest.phpclass file. - When in doubt about what to test, test a class's public interface. Protected and private methods are implementation details and may change, but public interfaces should, by definition, remain consistent.
- Don't test implementation details. In other words, don't make assertions about internal state, such as protected properties. This helps avoid brittle tests that might break because of changing implementations, even as the public interface they're testing stays the same.
- Use WP_Mock for mocking core WP calls. In other scenarios, avoid using mocks when possible: use real objects instead. If you have to mock several different things just to make an assertion about a single method, that indicates you may need to redesign your code.
- Pull requests that include new library code but no tests will be treated as low-priority. We may ask you to add tests before accepting.
- Exceptions to these guidelines are OK given reasonable justification.