Topic: What exist best practices in tSQlt?
Costs task to write units-tests for basis on MSSQL Server with an amount of stored procedures to 1500 pieces and an amount of tables in a DB about 600 pieces. The basis was written and supported by several developers within 12 years approximately, and now also continues to change periodically.
As the tool for testing I selected tSQLt - tsqlt.org/.
1. What practical favor the unit-testing can bring such.
That occurs at once - in a situation if to envelop everyone at least one positive test in a case when on one table of a DB depend a little , and the DB changes structure of the given table, then changes, let us assume, the code of one of , and about remaining , depending on the table, forgets, our test cases is expected fail on these , thereby signaling that its attention here is required. To put it briefly, regression testing turns out.
Whether any favor can be derived from such unit-testing still?
2. Widespread practice in test design - to search for boundary points and to write for them tests. But we imagine some tables which incorporate , let even only 3. How many test cases it is possible to make, that is how many various variants can be - when one table is empty, 2 others contain records, or on the contrary? The combinatorics prompts to us that such number will be calculated under the factorial formula. And still in there is a heap of different conditions on comparing with certain value this number still increases.
I.e. reasonable it is represented to write under one test for one in which it will be checked that the expected result of the test will be equal returned . As I will repeat, to me it is necessary to envelop, to 1500 .
What in this case can be best practices? Such approach has the right to life?