github.com/m3db/m3@v1.5.0/TESTING.md (about)

     1  M3DB Testing Patterns
     2  =====================
     3  
     4  `m3db` uses a combination of testing strategies, they're listed below for completeness.
     5  
     6  (1) Unit tests
     7  These are package local tests where we use mocks/stubs to ensure components interact with each other
     8  as we expect.
     9  
    10  These come in two flavours:
    11  - white-box: i.e. the tests know about the internals of the components they are testing, and may modify them
    12    (by injecting functions, changing consts) for testing.
    13  - black-box: i.e. when the tests do not know about the internals of the components they are testing, and rely
    14    on only the exported methods for testing.
    15  
    16  These are all run by the CI for every push, with race detection enabled, and code coverage within the package
    17  being tested.
    18  
    19  (2) Property tests
    20  We use a property testing library, [gopter] for generative tests. These allow us to specify input generators,
    21  and ensure the invariants expected on the system hold.
    22  
    23  [gopter]: https://godoc.org/github.com/leanovate/gopter
    24  
    25  These come in two flavours:
    26  - Vanilla property tests: used when we're testing `pure` functions (i.e. side-effect free).
    27  - System under test: used when we're testing stateful systems. The allow generation of input state,
    28    and the methods use to transition the state of the system.
    29  
    30  These are all run by the CI for every push, with race detection enabled, and code coverage within the package
    31  being tested.
    32  
    33  (3) Big Unit Tests
    34  These are a specialized version of the unit tests that are marked with the build tag `big`. They are heavier weight
    35  unit tests for which we disable race detection.
    36  
    37  These are all run by the CI for every push, with race detection disabled, and code coverage measured across all
    38  m3db packages.
    39  
    40  (4) Integration tests
    41  These tests are heavier weight tests that spin up one or more m3db DB's within a single process and test
    42  interactions with each other, and other components (e.g. etcd, read/write quorum).
    43  
    44  These are all run by the CI for every push, with race detection disabled, and code coverage measured across all
    45  m3db packages.
    46  
    47  (5) DTests
    48  TODO
    49