While the parameter resolution search scans parameter values from the test-case and test-set hierarchy, it may find partially complete parameter sets on different levels. These parameter sets are joined together to fill up the missing parameter values required for running the test case.

Consider the following example:

During the scan for parameters, the algorithm finds the 1st table, with only values for the ${fruit} parameter. These values are kept. The scan continues with the parent test set, which contains the second table, that has several values for the ${city} parameter. The join algorithm does a CROSS JOIN to join these two tables in order to produce the possible parameter combinations. the test will effectively run with the following four different parameter-rows produced by the Cartesian product:

The cross join can produce too many parameter-rows. If the parameter sets have few common columns, then a NATURAL LEFT (OUTER) JOIN is performed in a manner similar to a SQL database.

Consider the following example:

The resolution algorithm performs a join of the two parameter sets similar to the NATURAL LEFT JOIN in SQL. It joins the two tables using the common parameter (=column) names in the parameter sets. For all rows in the first set it joins all matching rows in the second.. A LEFT OUTER join is then performed, so that all rows in the first set are kept, even when there is no matching row in the second set.

The result in this case will be:

The test case runs five times, once for each row in this joined parameter set.

As shown in the previous examples, the joins can produce a large number of combined rows. The resolution algorithm limits to 10 the number of rows joined to one left row. This means that , if one row in the left parameters has more than 10 matching joined row on the right (using either natural or cross join) only the first 10 rows are joined, and the rest are ignored.

This helps to reduce the number of combinations.