Comment by Helmut10001
3 years ago
I would categorize this as part of integration testing, which I prefer above unit tests by light-years.
3 years ago
I would categorize this as part of integration testing, which I prefer above unit tests by light-years.
It can also be unit tests. You can take any function that has contracts defined and run a fuzzer (or a property testing generator) on its inputs, and its an isolated unit test.
Or you could generate input actions for the entire system to exercise all contracts, and get e2e tests.
Or you could run your code in production and exercise contracts (maybe at a certain sampling rate) to get observability and "testing in production".
Its the most powerful and flexible concept I know of, but it requires thinking in properties (pre/postconditions) which can be a bit tricky.
I agree, but unit tests are cheaper, you can do them unilaterally, and you can accomplish a lot with them in an organization that can't or won't invest in integration testing.
Even when integration tests exist, they typically don't go beyond exercising each ability of the system one or two ways. They don't achieve good "data coverage" or branch coverage, which is what property-based unit testing excels at.