Vokal Testing Standards

Every engineer at Vokal owns 100% of the code that they write, as well as 100% responsibility for the quality of that work. Code coverage for tests must be 100%, and coverage of the acceptance criteria must be 100%.

Each and every pull request must include tests for included features. Any pull request without tests will be rejected.

Automated Testing Guidelines

• 100% code coverage is always the goal
• Unit test will be written to cover each model
  • All public methods must be covered by unit tests
  • Sync methods that touch the network can be tested by using an injected mock network object
  • If something should be tested but is not public, make it public so that it is testable
    • Going against common practice to make code more testable is a good thing
  • Cover all convenience methods
• Automated tests will be written to cover each story in a given iteration
  • A story is not completed unless it has a written and operational automated test
• Automation must be 1:1 with the test plan
  • Some exceptions apply if the functionality cannot be tested automatically (like requiring external specialized hardware)
  • When adding a new case to the test plan, automated tests must be updated to reflect this

Testing Frameworks

Android and iOS

For Unit Testing use the testing frameworks included in the SDK (jUnit and XCTest, respectively).

For Android, use Espresso for UI/Acceptance testing.

Python

Django has an integrated test platform built on Python's unittest module, as well as a built-in test runner invoked with ./manage.py test. Flask projects use unittest with the nose test runner.

Go

Go has it's own simple testing package which works well enough for simple unit tests, though we often leverage the gocheck package for complete integration testing.

Web

Covered in detail here.

New frameworks

If you want to propose a new framework to replace any of the above, research it and present the framework to your discipline's team.