mirror of
https://github.com/cpm-cmake/CPM.cmake.git
synced 2025-11-17 22:58:14 -05:00
c58e98a0a0
* Initial commit for integration tests. Experimental. Playing with potential syntax
* Some experimental code to setup tests
* Piecewise building of CMakeLists
* First check
* Alternative approach. Using ruby's test/unit
* Parse CMakeCache. Separate lib
* First integration test
* Latest Format.cmake. Passing style
* Allow user-provided integration test dir. Allow reuse
* Separate class with utils for cache (no longer pure Hash)
* Allow running of tests from any dir
* Add integration tests to CI
* Use an in-source integration test directory
* Allow relative integration test dir from env
* Custom assertion for a success of CommandResult
* Windows-latest-latest
* Enrich CMakeCache class with more CPM data
* Added test for CPM-specific CMakeCache values
* Style
* Style
* test_update_single_package
* WiP for source cache test
* Small source_cache test
* Style
* Moved env clean to cleanup to make setup methods simpler (not require super)
* WiP for integration test documentation
* WiP for integration test documentation
* Project file creation tweaks
* Split docs into multiple files. Complete tutorial. Reference.
* Tips
* Typo
* Setup Ruby inistead of requiring windows-2022
* Revert "Setup Ruby inistead of requiring windows-2022"
This reverts commit 8aa2732145.
45 lines
2.8 KiB
Markdown
45 lines
2.8 KiB
Markdown
# CPM.cmake Integration Tests
|
|
|
|
The integration tests of CPM.cmake are written in Ruby. They use a custom integration test framework which extends the [Test::Unit](https://www.rubydoc.info/github/test-unit/test-unit/Test/Unit) library.
|
|
|
|
They require Ruby 2.7.0 or later.
|
|
|
|
## Running tests
|
|
|
|
To run all tests from the repo root execute:
|
|
|
|
```
|
|
$ ruby test/integration/runner.rb
|
|
```
|
|
|
|
The runner will run all tests and generate a report of the exeuction.
|
|
|
|
The current working directory doesn't matter. If you are in `<repo-root>/test/integration`, you can run simply `$ ruby runner.rb`.
|
|
|
|
You can execute with `--help` (`$ ruby runner.rb --help`) to see various configuration options of the runner like running individual tests or test cases, or ones that match a regex.
|
|
|
|
The tests themselves are situated in the Ruby scripts prefixed with `test_`. `<repo-root>/test/integration/test_*`. You can also run an individual test script. For example to only run the **basics** test case, you can execute `$ ruby test_basics.rb`
|
|
|
|
The tests generate CMake scripts and execute CMake and build toolchains. By default they do this in a directory they generate in your temp path (`/tmp/cpm-test/` on Linux). You can configure the working directory of the tests with an environment variable `CPM_INTEGRATION_TEST_DIR`. For example `$ CPM_INTEGRATION_TEST_DIR=~/mycpmtest; ruby runner.rb`
|
|
|
|
## Writing tests
|
|
|
|
Writing tests makes use of the custom integration test framework in `lib.rb`. It is a relatively small extension of Ruby's Test::Unit library.
|
|
|
|
### The Gist
|
|
|
|
* Tests cases are Ruby scripts in this directory. The file names must be prefixed with `test_`
|
|
* The script should `require_relative './lib'` to allow for individual execution (or else if will only be executable from the runner)
|
|
* A test case file should contain a single class which inherits from `IntegrationTest`. It *can* contain multiple classes, but that's bad practice as it makes individual execution harder and implies a dependency between the classes.
|
|
* There should be no dependency between the test scripts. Each should be executable individually and the order in which multiple ones are executed mustn't matter.
|
|
* The class should contain methods, also prefixed with `test_` which will be executed by the framework. In most cases there would be a single test method per class.
|
|
* In case there are multiple test methods, they will be executed in the order in which they are defined.
|
|
* The test methods should contain assertions which check for the expected state of things at varous points of the test's execution.
|
|
|
|
### More
|
|
|
|
* [A basic tutorial on writing integration tests.](tutorial.md)
|
|
* [A brief reference of the integration test framework](reference.md)
|
|
* Make sure you're familiar with the [idiosyncrasies](idiosyncrasies.md) of writing integration tests
|
|
* [Some tips and tricks](tips.md)
|