tcunit/TcUnit

Implement optional parameters for the test results

Closed this issue · 11 comments

On top of #68, also implement the following optional parameters in the test results:

  • Whether a test is skipped
  • Number of assertions for a testcase
  • failure message/type for a testcase
  • Something more?

As per request of a TcUnit-user, the information of whether a test has failed will be included as well.
image

Copy? How do you mean?
Here is a screenshot of it if that makes sense...
image

the result should not be in the st_testsuiteresults, as we only store the results there. The status-data is in the FB, as the variable: StoredTestSuiteResults + StoredGeneralTestResults. I can add a getter-method for these so that they are available.

A Getter will solve it cleanly yes.

When it's done ;-)

I don't think it's necessary with these getters, it will be redundant. You already got the information you need by first checking:
GVL_TcUnit.NumberOfInitializedTestSuites
And then for every test suite:
GVL_TcUnit.TestSuiteAddresses[TestSuiteNumber]^.AreAllTestsFinished()

If this is true, you know all tests are stored.
Look into:
FB_AdsTestResultLogger.LogTestSuiteResults()

of how this is utilized.

Suggestion!

I'll pass the instance of FB_TestResults as a pointer into my FB.
Then I can access its method and properties without problems.

No, I really do not agree on that last suggestion. In my opinion that cure is worse then the disease. The answer should be publicly published, as it is a bad practice to calculate the same answers in multiple places, with all troubles in future code updates. Plus, a ‘getter’ will not solve the public publish question as my FB consumes only ITF_TestSuiteResults. The getter is not inside that Interface so the third party FB cannot read the getter. Looking forward to other suggestions.

You're right, it was a bad idea.
I would create an interface, such as I_TestResults, implement the method and do a dependency injection of that into all FBs that are dependent on it.

I'm not using properties in TcUnit so it would be nice to be consistent.

I've commited the code with the interface now. Look at the AdsTestResultLogger of how it is dependent on the TestResults.

Solved in 1f2da3a.
All optional parameters mentioned are implemented in the test results collector as well as included in the ADS test logger.