Advice for handling parameterised / permutations of unit tests minimising copy/paste

[Greedquest]

Hi Ducks,

I'm doing some TDD (test driven development) . I've written a dozen unit tests, each of which relies on a module level subject under test that wraps some objects in its constructor.

I now want to run the same suite of tests with a slightly different wrapped object, or slightly different parameters to the constructor.

At the moment in the test module I basically have this setup:

Private Assert As Rubberduck.PermissiveAssertClass
Private Fakes As Rubberduck.FakesProvider
Private srcTable As ListObject 'parameter to the sut constructor
Private sut As TableWatcher

'@ModuleInitialize
Private Sub ModuleInitialize()
    Set Assert = New Rubberduck.PermissiveAssertClass
    Set Fakes = New Rubberduck.FakesProvider
End Sub

'@TestInitialize
Private Sub TestInitialize()
    TestSheet.Reset 'resetting the testsheet resets the demo table to a repeatable starting condition
    Set srcTable = TestSheet.DemoTable
    Set sut = TableWatcher.Create(srcTable)
End Sub

'... Tests rely on sut which should be set up correctly

Where every test shares a module level sut (subject under test). So if I want to make a new suite of ntests run on TestSheet.TableWithNoRows or TestSheet.TableWithASingleColumn or any other edge case, I can just duplicate the entire module and tweak that setting. Or extract all of my test bodies into parameterised functions; but still their calling sites need to be duplicated for each combination of parameters. I could also loop through a collection of parameters in each test but the @TestInitialize code would also be required to run multiple times per test and that is not the flow RD uses...

What would you recommend for now?

[Vogel612]

There is a very old related issue: #1229, not that it helps with the discussion at hand.

As of now it's impossible to hook into the unit-testing engine itself to run tests with different parameters, which means that you will have to implement some form of that yourself. I'd actually expect each invocation of a @TestMethod that has arguments provided by the test engine to be handled as if it was it's own @TestMethod where the arguments are procedure-scoped constants... (This would also simplify rerunning failing test cases for data driven tests). There is unfortunately no nice way to implement this behaviour yourself, since an assertion failure terminates the test method.

[Greedquest]

An assertion failure terminates the test method

Hmm yeah that really sucks. Although I guess often it's sufficient to know the first test that failed. But definitely not ideal, as if you see many failed it probably is a different cause to if just one has.