The 'oneview-sdk' source code provides a unit, integration/functional, and system testing strategies. It also provides linting tools to ensure its code style.
This document will cover how to execute and implement them.
The tests can be executed by rake tasks, guard watches, and by their original tools, like rspec, and rubocop.
All the test strategies and checks can be executed by the rake command.
Please use rake -T to see a full list of commands.
Guard will watch the changes and execute unit tests and style checks. Just activate it to have real time test execution on every change.
All unit tests are inside the spec folder. You can execute them manually by using RSpec and specifying the test files, like rspec spec/unit/path/to/my/tests.
The integration tests are responsible for checking if the oneview-sdk is correctly integrated with the OneView appliance, at the same time it tests its functionalities.
Each integration test has its own pre-requisites and leaves the appliance in a different post state, and given OneView composable nature, each resource needs other resources configured so it can work.
The most top-level resources would need the appliance entirely configured, and setting up and tearing it down for each test would cost a lot of time (likely days). So there is a chained dependency among the tests to greatly reduce its execution time.
The integration tests are split into 3 categories create, update, and delete that can be run separately to allow some level of modularity between them.
System tests are integration-like tests, but they aim to test the whole solution executing more complex interactions (use cases), not just focusing in testing one endpoint.
The tests issue a coverage report generated by SimpleCov. To see the full coverage report it is needed to run the entire suites for each individual test strategy. For instance, if a full integration coverage report is needed it is necessary to run the three testing categories.
Style checking is done by rubocop for all the checkable code.
All code must have associated tests, be it the already implemented or newly submitted, and this section covers what tests need to be implemented.
The unit tests are required for each new resource, bug fix, or enhancement.
The integration tests are required for each new resource, bug fix, or enhancement as far the new code modifies or adds an interaction with OneView.
To avoid incompatibility between tests, the integration has a consolidated configuration file with all the resource names and a dependency matrix called sequence_and_naming.rb.
It is far beyond from not advisable to instantiate a OneView resource in the integration tests that does not use the names in established there, if necessary, add the new names there.
Add the new resource implemented to the dependency matrix, so the testing requisites will be met.
Note: It is uncommon for an updated resource to change its dependency order, but it is fairly possible.
Some resource methods behave exactly like other ones, so the source code provides a shared tests folder that can be used along multiple resource tests.
The necessary amount of testing is dictated by who is implementing and by who is reviewing and accepting the code, however, there is a floor coverage acceptance level defined in the spec_helper.rb file.
System tests focus on use cases and they may be implemented to cover specific scenarios not covered by the other test strategies. Different from the unit and integration tests they do not have an acceptance criteria.