LabVIEW problems with unit Test under lvoop

[dpnsw]

Hi,

I am trying out the Unit Test Framework now included with LV2012 with some LVOOP code but seem to be running into some problems.

I have constructed a unit test for a basic class in the attached project which is the source class (There is another class in the project as this is an example of a retrieve method but it is not used in the unit test). My problem is that I get results that fail for one of my tests when I think they should work.

Basically the unit test is set up as the following

Case 1) Test the VI without the setup VI and ensure default values work

Case 2) Test VI by setting specific values in the setup VI and test them at the Teardown VI and also check the single output from "Source Method.vi"

Case 3) Test the VI with the setup VI using it's default values and confirm them via the Teardown VI

When run Case 2 fails and reports that the Teardown VI is returning default values not those fed in from the Setup VI. I can't see why.

As per

Any suggestions?

All the best

David

[Thomas-B]

Hi dpnsw, 

I've downloaded your files and am running into the same issues. It aopears to be always reading the default values out of the Source Read Cluster, but since cases 1 and 3 both expect those values, those two cases pass. Whenever you run Case 2, since the expected values have been set to be the input values of the Source Write Cluster, it compares them with the default Source Read Cluster values, and fails. If you run the VI, since it passes the Source Write Cluster values to the Souce Read Cluster Values, all three cases fail in subsequent tests. That being said, I have not figured out exactly what needs to be done to pass all three tests. I'll continue to look into it, and will let you know if I find anything. Let me know if you make any progress.

[dpnsw]

Hi Thomas,

Thankyou for checking this out.

The thing that is puzzling me is that when I run the "SourceAccess Unit Test Manual.vi" and if I have the Source Method.vi open I see the value on it's Source indicator change to be that of the Numeric 3 from the Test VI. Once the value is changed it seems to stay. I thought that once a VI completed that LabVIEW did the memory clean up and the object should no longer exist. This doesn't seem to be happening. If I change the values on the input control for the test vi then these changes are remembered next time the Source Method.vi is run. If I exit the project and come back in only then does the SourceAccess object appear to have been cleaned up (garbage collected).

What I need to understand is what is the expected behaviour with this. From what I can see the Unit test is correct but I am actually having problems with the way the class is behaving.

I played around with some of the execution settings thinking it may be because it was keeping state when it shouldn't but none of the re-entrance or even inlining seemed to help.

Any light you can shed on this will be helpful.

All the best

David

[Thomas-B]

Hi dpnsw, 

I've done some more research into the unit test and LVOOP question you had and I believe I have found a solution. It appears that both the OOP code you wrote and the unit tester were working properly. However, there was one small issue with the unit test configuration. The inputs and ouputs weren't designated in the setup and teardown section of the unit test properties window. Tests 1 and 3 still executed properly and passed because they were simply outputing default values. However, Test 2 was failing because it was asking the VI to pass values through without telling it how. Basically, it was "unwired". I have attached a screen shot of what Setup/teardown configuration allowed the unit test to pass all three cases. This configuration tells the VI how to pass the values properly. 

I hope this is helpful

[dpnsw]

Thomas,

Thankyou very much for that. That was it. Now understand why it didn't work.

There does however remain one perplexing problem which is why Source Method.vi when I run it after running the SourceAccess Unit Test Manual.vi it reports 1000 for the source value rather than 3. I don't understand how or why this happens.

Source Method pulls it's data from Numeric 3 in the Source Access Object which is in the Source Access.ct. That control is a strict typedef of EDP Cluster.ctl

When I used the strict typedef EDP cluster.ctl in the SourceAccess Unit Test Maual.vi this created problems as it seemed to propogate back "make current values default" back into the typedef.

I disonnected the control from the typedef and that seemed to fix part of the issues however when I run Source Method.vi after running the "sourceAccess Unit Test Manual.vi" the source indicator always reports 1000 not 3 as I would expect.

This seems to have something to do with object creation and destruction. I thought an object was destroyed when it went out of scope or the VI stopped running such that if I run the same VI 10 times it is not using the same object. Is the right or wrong?

Many thanks

David

[Thomas-B · Accepted solution]

Hi David, 

The behavior you are describing is expected. When you first call the "Source_Method.vi" using the "SourceAccess Unit Test Manual.vi", the "SourceAccess Unit Test Manual.vi" creates and instance of the "Source_Method.vi". In this specific instance of the VI it will initialize with default values but will then retain the values that it is passed by the "SourceAccess Unit Test Manual.vi" until the project us closed, or you specifically tell it to reinitialize to its default values. Each time it is called by  "SourceAccess Unit Test Manual.vi" it will access this instance of it. If another instance of the "Source_Method.vi" were created by another parent it would initialize with its default values, until overwritten by the upper level VI calling it. It would then behave exactly like the instance created by the "SourceAccess Unit Test Manual.vi". Regardless of your type of typedef and its setup, as long as everything is wired correctly, this should be the expected behavior when setting things up through Object Oriented Programming in LabVIEW. 

I hope this information is helpful to your application. If you want to see a LabVIEW example that shows this behavior you might consider referring to parts of the ReferenceObject.lvproj. It can be found by searching object-oriented in the LabVIEW example finder. This is accessed through

Help>> Find Examples.