mirror of
https://github.com/VictoriaMetrics/VictoriaMetrics.git
synced 2024-11-21 14:44:00 +00:00
7c60d82215
### Describe Your Changes This PR continues the implementation of integration tests (#7199). It adds the support for vm-single: - A vmsingle app wrapper has been added - Sample vmsingle tests that test the VM documentation related to querying data (#7435) - The tests use the go-cmp/{cmp,/cmpopts} packages, therefore they have been added to ./vendor - Minor refactoring: data objects have been moved to model.go Advice on porting things to cluster branch: - The build rule must include tests that start with TestVmsingle (similarly to how TestCluster tests are skipped in master branch) - The build rule must depend on `vmstorage vminsert vmselect` instead of `victoria-metrics` - The query_test.go can actually be implemented for cluster as well. To do this the tests need to be renamed to start with TestCluster and the tests must instantiace vm{storage,insert,select} instead of vmsingle. ### Checklist The following checks are **mandatory**: - [x] My change adheres [VictoriaMetrics contributing guidelines](https://docs.victoriametrics.com/contributing/). --------- Signed-off-by: Artem Fetishev <rtm@victoriametrics.com> Signed-off-by: hagen1778 <roman@victoriametrics.com> Co-authored-by: hagen1778 <roman@victoriametrics.com>
47 lines
2.4 KiB
Markdown
47 lines
2.4 KiB
Markdown
# App Integration Tests
|
|
|
|
The `apptest` package contains the integration tests for the VictoriaMetrics
|
|
applications (such as vmstorage, vminsert, and vmselect).
|
|
|
|
An integration test aims at verifying the behavior of an application as a whole,
|
|
as apposed to a unit test that verifies the behavior of a building block of an
|
|
application.
|
|
|
|
To achieve that an integration test starts an application in a separate process
|
|
and then issues HTTP requets to it and verifies the responses, examines the
|
|
metrics the app exposes and/or files it creates, etc.
|
|
|
|
Note that an object of testing may be not just a single app, but several apps
|
|
working together. A good example is VictoriaMetrics cluster. An integration test
|
|
may reproduce an arbitrary cluster configuration and verify how the components
|
|
work together as a system.
|
|
|
|
The package provides a collection of helpers to start applications and make
|
|
queries to them:
|
|
|
|
- `app.go` - contains the generic code for staring an application and should
|
|
not be used by integration tests directly.
|
|
- `{vmstorage,vminsert,etc}.go` - build on top of `app.go` and provide the
|
|
code for staring a specific application.
|
|
- `client.go` - provides helper functions for sending HTTP requests to
|
|
applications.
|
|
|
|
The integration tests themselves reside in `tests/*_test.go` files. Apart from having
|
|
the `_test` suffix, there are no strict rules of how to name a file, but the
|
|
name should reflect the prevailing purpose of the tests located in that file.
|
|
For example, `sharding_test.go` aims at testing data sharding.
|
|
|
|
Since integration tests start applications in a separate process, they require
|
|
the application binary files to be built and put into the `bin` directory. The
|
|
build rule used for running integration tests, `make integration-test`,
|
|
accounts for that, it builds all application binaries before running the tests.
|
|
But if you want to run the tests without `make`, i.e. by executing
|
|
`go test ./app/apptest`, you will need to build the binaries first (for example,
|
|
by executing `make all`).
|
|
|
|
Not all binaries can be built from `master` branch, cluster binaries can be built
|
|
only from `cluster` branch. Hence, not all test cases suitable to run in both branches:
|
|
- If test is using binaries from `cluster` branch, then test name should be prefixed
|
|
with `TestCluster` word
|
|
- If test is using binaries from `master` branch, then test name should be prefixed
|
|
with `TestVmsingle` word.
|