VictoriaMetrics/apptest/README.md
Artem Fetishev 7c60d82215
tests: integration tests for vmsingle (#7434)
### 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>
2024-11-07 12:58:37 +01:00

2.4 KiB

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.