How to reuse code in repetitive Unit Tests

[lpillsbury]

So I have an application where a variety of status words can lead to the same state in my code. I want to test all of the status/state combinations and started out by making one test per state where within the test I kept changing the status word and redoing my assertions. After a closer look at the FB_Sum_Test example, I thought, "better to make my code very modular, let me make one test per status/state combination". That worked alright, but I was cutting and pasting lots of code... which seemed bad. I then tried sending the status to the argument of my test... ie:

// OFF1
VFD_Disabled_Test(statusWord := 2#0111_0000);
VFD_Stopping_Test(statusWord := 2#0111_0000);

// OFF2
VFD_Disabled_Test(statusWord := 2#0110_0000);
VFD_Stopping_Test(statusWord := 2#0110_0000);

which makes for cleaner (and fewer) methods within my test function block, BUT... I can't run the same Test multiple times in one test suite. In attempting to, I get the totally reasonable error:

Test with name 'VFD_Disabled_Test' already exists in test suite 'PRG_TEST.fbVFD_ctrl_test'

I've seen other posts on this forum about people bundling tests and I'm wondering how others deal with this type of situation. Or is this just a case where it's necessary to have something like VFD_OFF1_Stopping_Test, VFD_OFF2_Stopping_Test etc even though all the tests are basically the same? If I need all these individual tests, would it work to outsource the assertion parts of the test to a function that I reuse or must the AssertEquals() be in the test itself?

[lpillsbury]

I'm going to reply to myself here and say that I ended up deciding to loop through all the possible status-words in each test. This way I had fewer additional functions and no repeat calls to tests. This seems like a cleaner way to approach it than what I had; I'd still be curious to know what other people do in this situation.

[Aliazzzz]

You can declare a testmethod named:

METHOD VFD_DynamicTest : BOOL
VAR_INPUT
   TestName : T_MaxString; // Test Name
   ExpValue: WORD; // Expected Value
   MyVFD : POINTER TO FB_VFD;
   FailMsg : T_MaxString; // Fail Message
END_VAR

And the code (example)

IF TEST_ORDERED( TestName ) THEN

   (* Stage this Test Here *)
   MyVFD^.Cmd( 2#0110_0000 ) ;  /// Writes Some command to the testee
   ExpValue := MyVFD^.Status();

   (* Assertion Here *)
   AssertEquals_Word( Actual := MyVfD^.GetStatus(),// Some code which provides the current object Status
                                  Exp := ExpValue, // Some code which provides the expected value
                                  Message := FailMsg );
   TEST_FINISHED();
END_IF

The Call

VFD_DynamicTest( 
   TestName := 'VFD Test1 Testing VFD Disabled',
   ExpValue := 2#0111_0000,
   MyVFD := ADR( Testee );
   FailMsg : 'VFD Test1 Testing VFD Disabled FAILED' );

VFD_DynamicTest( 
   TestName := 'VFD Test2 Testing VFD Disabled',
   ExpValue := 2#0110_0000,
   MyVFD := ADR( Testee );
   FailMsg : 'VFD Test2 Testing VFD Disabled FAILED' );

Be sure to call the testSuite

TcUnit.RUN_IN_SEQUENCE

I use this way of repeated testing all the time and works like a charm.

With kind regards,

Aliazzz

[Aliazzzz]

1. Usually most tests are running against a single instance of the FB, so it is a trade-off between speed and memory.
   My personal taste is to have 1 "Testee" (the object under test) and several tests who obviously never should run "parallel" as that will cause issue's in complex FB's. Once you have FB's that are complex like timer or state dependent FB's, RUN_IN_SEQUENCE is highly advisable.

2. The above actually anwsers 2 also but for completeness you can point to any MyVFD instance you see fit from somewhere in the program or testsuite.
   I am personally not such a huge fan of using VAR_STAT in methods so I chose to point to an external Testee via a pointer. Opinions may vary but it is a matter of Taste.

Generally you have at least 3 tricks to solve it:

1. VAR_STAT with local METHOD scope only (but using the main body Stack!)
2. VAR in Local main body with full local scope so everywhere available in throughout the body, methods and properties of this body
3. Method with some pointer, reference or interface as input (one could argue that these 3 are counted individually but I see them as fairly similair mechanisms with subtle differences)

Hope this explains it

[lpillsbury]

Thank you for this clear explanation. Let me go give this a try :)

[Bulkje]

Imo each unit test should make its own instations of the FB's that are tested. If this is not done, the changes made by a unit test to the FB can have effects on other unit tests. Ideally each unit test should be able to be tested separately. Other unit testing frameworks even take it a step further, JUnit randomizes the order of tests to ensure there are no dependencies.

[Aliazzzz]

@Bulkje you are correct but not all function blocks, especially those with state machines in them are not suited for this approach and you will find that those are more difficult (test case code is complex) and burner plate code intensive to test this way. So having a Single FB instance which is state dependent under test via several tests "contradicts" the normal aproach in favour of small burnerplatecode and readability instead of large overhead to tackle the state driven behaviour.

Sure, non state dependent FB's could be tested "as-is" with no dependencies with other test whatsoever which is fine and simple.
Randomization of the test order is a nice feature but doesn't actually add significant value if the rules of TDD are followed.

If you have an example of an FB with an embedded Statemachine under test, we the community, are interested in how you wrote your code in order to test the FB.

I hope to see your example code so I can study your solution =)

[Bulkje]

Testing some state based FB's is boilerplate intensive, I agree. To manipulate these FB's easily for test setup, I use helper methods. That way, code reuse is minimized, while you still have separate instances for each unit test.

For a state machine, imagine the helper method stoppedToExecute, that takes a VAR_IN_OUT statemachine and manipulates it in however many cycles your implementation of state machine needs, and then returns the state machine in execute to run the test.

[Aliazzzz]

"That way, code reuse is minimized." => you probably mean reuse is maximized as code duplication is minimized ;-)

So your approach is to have helper methods to skip or manipulate the state machine into the desired testing state and then do the required test. Yes, this seems a valid approach which also allows for randomization and thus should prove that there are no interdependences between testee or separate tests. The randomization is as said before, just an extra cherry which you could do without.

Primer In short:
The TEST_SUITE for some FB_UNDER_TEST contains several TEST_METHODS.
The TEST_METHODS call either helper METHODS and/or helper FUNCTIONS to manipulate the internal state of FB_UNDER_TEST into the desired starting state for test at hand. Since the code is encapsulated in Methods (and/or Function) we can prevent code duplication and promote code re-usage.

Sometimes the anwser can be so easy!