Recommendations for testing devices at an object with many properties

Question

I am new to unit testing, but I fully understand the idea of ​​testing individual units of code that perform a specific, verifiable task, however, I am in a state where I need to write tests and ensure confidence in the accuracy of the output of a method acting on an object with more than 50 properties. Combinations of the values ​​of these properties cause an output based on the rules entered from the rule definition object (using lambda expressions), which is essentially equal to the percentage. These output percentages are “critically important” and have been rather lazily tested before, for example, the quality of the rule definition class (all the component percentages for each rule are up to 100%), but the actual properties of the object were not.

The data object comes from the database, but I can, of course, mock it. My problem is the number of permutations of the data that would need to be mocked, and the number of tests that would need to be written to ensure that the x, y, z data (50 times odd exponential) seem almost impossible.

So, the question is how these situations are tested in the real sense. Are test scenarios based on the known “correct” state and “correct” results even possible / reasonable? Are unit tests applicable in this case, and if not, what alternatives exist.

By the way, this is outdated code here with a little refactoring ability, but only if I can guarantee accuracy, etc. in a few days to do both refactoring and tests!

Answer 1

I think you yourself gave half your answer:

Combinations of the values ​​of these properties give an output based on the rules introduced from the rule definition object (using lambda expressions), which are essentially equal to the percentage.

In the current unit test, you will be ridiculed by both the data and the rule . Therefore, you only need to make sure that the input and output methods behave correctly.

Testing a rule is a different task. I can only guess, but usually you will have an Excel spreadsheet or something like that of the possible values ​​of the inputs and outputs to indicate the requirements for this rule. I would convert the same table into a readable format (csv) and use it directly to control the unit test rule.

Answer 2

If this is a huge number of combinations that keep you from trying to create test patterns, you can take a look at all-pair testing .

We used PICT from microsoft to successfully minimize the number of test boxes, while still having reasonable assurance that most cases are covered.

Summary

For example, if you want to create a test suite for a partition and create a volume, the domain can be described by the following parameters: type, size, file system, formatting method, cluster size, and Compression. Each parameter has a limited number of possible values, each of which is determined by its nature (for example, compression can be turned on or off) or as an equivalence section (for example, size).

Type: primary, logical, single, space, strip, mirror, RAID-5
Size: 10, 100, 500, 1000, 5000, 10000, 40,000
Formatting Method: Fast, Slow
File System: FAT, FAT32, NTFS
Cluster Size: 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536
Compression: on, off

There are over 4700 possible combinations of these values. It will be very difficult to test them all in a reasonable amount of time. Studies show that testing all pairs of possible values ​​with good coverage and the number of test cases will remain manageable. For example, {Primary, FAT} is one pair, and {10, slow} is another; One test case can span many pairs.

For the parameter set shown above, PICT will produce 60 case tests.

Unloading points

• there are more than 4700 possible combinations
• PICT will create 60 test cases

All couples

The rationale for testing all pairs is this: the simplest errors in a program, usually one input parameter.

The next simplest category of errors consists of interactions dependent between pairs of parameters that can be caught checking all pairs.

Errors related to the interaction between three or more parameters are gradually less common, while at the same time, a gradually more expensive search is made for exhaustive testing, which has as its limit exhaustive testing of all possible inputs.

Answer 3

Well, I don’t know what language you work in, but, looking in my profile, I think .Net can be involved.

If I'm right, I would suggest using Data Driven Tests. MSDN provides a short quick start that really helped me do the following: How to create a data-driven Unit Test Since I read this article, I started to come up with a new variation to use in every new project ...

Working with these DDTs in Visual Studio allows you to store your test datain data in XML, CSV, or in a database table. Perhaps you can write code to generate the necessary values ​​to insert into the tests?

The second tip is the Microsoft Pex and Moles project, which analyzes your system under test and automatically generates test data on this basis to find more extreme tests.