Even smaller boilerplate code => TEST('....') as an implicit functionality?

[Aliazzzz]

With the pragma {attribute 'call_after_init'} not necessary anymore, maybe it is also possible to implicitely call TEST('SomeTestName') somehow. That way the function name of test method can act as the test name.

Current;

METHOD PRIVATE TwoPlusTwoEqualsFour
VAR
..
..
END VAR

TEST('TwoPlusTwoEqualsFour')
..
..
TEST_FINISHED()

Suggestion

METHOD PRIVATE TwoPlusTwoEqualsFour  // possible to somehow use as implicit test name?
VAR
..
..
END VAR

//TEST('TwoPlusTwoEqualsFour')
..
..
TEST_FINISHED()

Is this feasable? If so, is it difficult to implement?

[KubaO]

It is possible to get the method name. The binary image in the PLC has a function/method table that has names of all the functions. Given the address of the method, one can walk the entire function pointer table, and look up the details of any function. You'd get its address without using ADR(MethodName) by reading it from the stack frame.

Let's say we have:

METHOD PRIVATE TwoPlusTwoEqualsFour
....
AssertEquals(.....)
....
TEST_FINISHED()

Then, AssertEquals calls something like TEST(GetMethodName(1)) where 1 indicates the number of stack frames separating GetMethodName from the method that is to be queried (here: one, it's just the stack frame of AssertEquals).

I have a proof of concept of GetMethodName for x64, and can definitely share it once I get it to work for x32. It should be portable to ARM as well, I'd hope. It'd probably work on CoDeSys as well, as long as the details of the code generator and runtime linker don't differ in the key areas.

[sagatowski]

@Aliazzzz I like the idea.

Would be an interesting option, as long as it in no way breaks the current way of doing it as I've seen users doing it in all kinds of ways, for example:

• Not calling TEST('xyz') with the same name as the method itself (so for example calling TEST with xyz while the method is called abc)
• Not using methods at all, but just putting all the tests directly in the test-suite function block body
• Using several TEST() in one method

There's probably more ways of doing it :-)

[KubaO]

It is possible to ask for multiple names on the call stack, and then you'd name the tests according to some filtering principle, most likely user-provided. I.e. the user could implement an optional function that, given a function name, returns a null or a test name. The call stack would be walked one frame at a time until a valid name is found.

[Aliazzzz]

Would you be so kind and post an example or so?

[Aliazzzz]

I think this addition of a yet even smaller burner plate code will be much appreciated.
The test function can be privatly called on init once per testsuite per test mehod and in combination with the reflection pragma to call this function explicitly outside of the user space.
Unittests are seldomly instanciated in runtime (though this is possible via __NEW() ) I'd not recommend such antics.

[sagatowski]

@Aliazzzz I'm not sure I follow this. Could you provide an example?

[Aliazzzz]

My idea is the following;

Every FB has an implicit initialization method we can use ( fb_INIT ).
In this initialization we can (hopefully) iterate through each test method declared in the main
body of the testsuite in fb_init and call;

TEST( name_of_test_method_without_path_obtained_via__path_reflection );

Now we don't have to call TEST('foo') in the test-method itself anymore as this is automatically achieved on initialisation of the suite.

[sagatowski]

How do we iterate the test methods in FB_Init? And how do we get their names?
How do we differentiate between the different test-methods and any eventual help-methods the user might have put there?

[Aliazzzz]

All good questions on which I don't have an anwser at this time. @KubaO had an idea, but has not provided an example on it yet. Have you got a suitable idea on how to tackle this?

[Roald87]

Maybe a way to get the method names is to just read the TcPOU file and extract the method names using an xml reader? Not the nicest solution, but should work I think.

Getting rid of TEST('..') is a good idea. Also because it would enable it to stop calling the methods once they are finished. Or is there currently already a way to stop calling a method?

[I-Campbell]

It seems the keyword __POUNAME is in the future for TwinCAT. This would be useful if each test case was an FB [#107]
https://help.codesys.com/webapp/_cds_operator_pouname;product=codesys;version=3.5.16.0
I know it is not super helpful yet.

[Roald87]

@I-Campbell sounds useful, but this is actualy already possible currently in TwinCAT. It is also used in the TcUnit library. You can see it in use in FB_TestSuite:

{attribute 'call_after_init'}
{attribute 'reflection'}
FUNCTION_BLOCK FB_TestSuite
VAR
    {attribute 'instance-path'}
    {attribute 'noinit'}
    InstancePath : Tc2_System.T_MaxString;
...

More info: https://infosys.beckhoff.com/content/1033/tc3_plc_intro/2529681547.html?id=8053634368777910140

[I-Campbell]

instance-path (eg. PLC_PRG.myInstance) is slightly different to __POUNAME (eg. FB_TestSuite), but you are right, it could solve the same problem AND it is available today.

[Roald87]

Yes getting direct access to the POU name would be much more convenient of course!

[sagatowski]

It's nice to see get these tips about new functionality in codesys, surely we will see it further down the road in TwinCAT and it might be useful for TcUnit as well. Only thing I'm afraid of is breaking compatibility to Tc 4020/4022/4024 (like compatibility was broken to 4016/4018 with the introduction of ANY).

[DavidHopkinsFbr]

It is possible to get the method name. The binary image in the PLC has a function/method table that has names of all the functions. Given the address of the method, one can walk the entire function pointer table, and look up the details of any function. You'd get its address without using ADR(MethodName) by reading it from the stack frame.

It is possible to ask for multiple names on the call stack, and then you'd name the tests according to some filtering principle, most likely user-provided. I.e. the user could implement an optional function that, given a function name, returns a null or a test name. The call stack would be walked one frame at a time until a valid name is found.

@KubaO I've been looking for more information on accessing TwinCAT/CoDeSys call stack, symbol tables, and method definitions at runtime, but I can't find any documentation or even blog posts. Can you give me any pointers?

I've been trying to figure out how to write something similar to Tc3_JsonXml FB_JsonReadWriteDataType.SetSymbolFromJson but I can't figure out what magic the library is using to iterate over the fields contained in a target struct and determine the correct data types for each field. It doesn't seem to use the Tc2_Utilities PLC_ReadSymInfo FBs since it's synchronous and doesn't accept any ADS-related parameters.

EDIT: Looks like the __VARINFO() operator is what you use for runtime reflection in TwinCAT. So that's useful for parsing strings and using the results to set values in arbitrary IEC61131-3 data structures. I still have no idea how to read the TwinCAT/CoDeSys call stack at runtime though. Clearly it's possible, since TwinCAT XAE has a Call Stack debugging window...

[KubaO]

There's no documentation for any of it, just reverse engineering. You'll start by writing a procedure that reads the stack and dumps it out in hex so that you can see it. Then you can try following some pointers on the stack and see what other data they lead to. The pointed-to- areas should be dumped hex + ascii so that you can notice where names are. I have worked on it a good while ago, and I don't have access to that code anymore. However, I can see what I have in my notes about it.

[sagatowski]

@DavidHopkinsFbr Maybe something for the local Beckhoff support to help answering?

[sagatowski]

@DavidHopkinsFbr Did you manage to get any information from Beckhoff?

[sagatowski]

For what it's worth, I've been using __POUNAME() in 4026 and it works beautifully.
So:

TEST(__POUNAME())

AssertEquals_...

TEST_FINISHED()

No more copy-n-pasting test names from method declaration into the implementation.