Test Coding StandardsIn order to write successful and uniform tests, coding standards would have to be set for the development of tests. These standards specify how tests should be written and what should be tested.5.1 General standardsNamingOrganization5.2 Unit testsThe unit test coding standards have been split up into three parts one for unit tests in general, one for testing components and one for stores. The reason for stores and components having different standards is that they work in different ways so their setup is very different from one another.

Each unit test will follow this structure:Set up the test dataCall the method under testAssert that the expected results are returnedAs mentioned in the chapter 4.3 Code Uniformity linter is being used in Penneo, it was also decided to create specific Linter rules for the tests. On top of the already mentioned rules, Jest specific rules were added (https://github.com/jest-community/eslint-plugin-jest):Disallow disabled tests.

Jest has a feature that allows to temporarily mark tests as disabled. It is often used for debugging or creating the actual tests. However before commiting changes to GitHub all tests need to be running. Disallow focused tests. This rule is very similar to the rule above. Jest can also focus on running only one test which is particularly helpful for debugging a failing test, so all of the tests do not have to be executed while doing that which with a big amount of tests could annoying. This rule ensures execution of all the tests (not only one) on Travis.

Disallow importing Jest. Since the `jest` object is already automatically in the scope of every test file it is unnecessary to import it. Furthermore `jest` object does not export anything anyway. The methods for creating mocks and controlling Jest’s behaviour are part of the `jest` object.Suggest using `toHaveLength()` to assert object’s length property in order to have a more precise failure message. Enforce valid `expect()` usage.

This rule ensures that the `expect()` is called with a single argument only and that the actual expectation has been made.Disallow identical titles. Having tests with identical titles within the same test suite may create confusion, especially when one of them fails it is harder to know which one failed and should be fixed.5.2.2 Testing componentsWithin the wrapping `describe` clause of a components test suite write “Component” within square brackets followed by the components name (e.

g describe(Component ComponentName)).Always start with writing a minimal component test which confirms that component rendered, then test behaviour.Use explicit `setup()` over `beforeEach()`, so it is clear how the component was initialized in the specific test.All interaction with external modules should be mockedPut tests close to the files they test and name test files with a `.

test.js` extension.5.2.

3 Testing storesWithin the wrapping `describe` clause of a stores test suite write “Store” within square brackets followed by the store name (e.g describe(Store StoreName)).Mock every module except the one that is being tested in order for a unit test to operate on a fully isolated unit of code.Before each test, set up an access to the store’s registered callback. Since the application’s dispatcher is thoroughly mocked the Flux data flow has to be simulated.

Before each test clear the store so it has its initial state for another test.If helper functions are needed they must be defined outside of testsEvery store test suite must have a test that checks whether a callback has been registered with a dispatcher.Put tests close to the files they test and name test files with a `.test.

js` extension.5.3 Functional testsThe standards for writing functional UI tests got split up into two parts. First one treats about a recommended way for creating well designed Cucumber tests, the second one talks about good practices and standards that have been followed related to writing WebdriverIO tests.