Auto-populate unit tests

[bokorpet]

Hi,

I'd like to dynamically include unit tests (lvtest) in a project A from various other projects B1, B2, etc., i.e., when I add a new test say in B2, it gets added to A automatically.

"Auto-populated folders" don't seem to work here: unit tests return with an error "class cannot be loaded" (some other text in German).

It seems to me that unit tests get corrupted during auto-population.

When I add a unit test manually from project B2 (via add & browse), the unit test runs without errors.

Any idea or workaround?

Thanks,

Peter

[Chris13]

Hello Peter,

could you please upload the error message for us?

E.g. I am german and can say something about it, or do some research.

Thank you,

have a nice evening,

Best regards!

[bokorpet]

Hi Christopher,

thanks for your support.

We found (in our setup) that

1. (ERROR) All unit tests of a project (added within this project or auto-populated from other projects) result in an error ("Mögliche Ursachen: LabVIEW: Die Klasse konnte nicht geladen werden.") if the unit tests assume "cyclic inheritance dependency"; by cyclic inheritance dependency I mean that the current project contains a class C such that C inherits from a class A and A and its unit tests are located in an auto-populated folder;

2. (SUCCESS) Unit tests located in auto-populated folders without cyclic inheritance dependency result in the same execution as in their originating projects -> for us the expected behavior.

   Does it make sense to you?

Peter

[Chris13]

Good evening Peter,

unfortunately this does not make sense for me. Could you create a minimal example project which shows the same behaviour and upload this here?

I also have to say that I don't have much experience with classes and inheritance. But I'll give it a try!

Looking forward to hearing from you,

best regards!

[JÞB]

This one is surprising me as well and I just can't put my finger on why you would want to do this.

Library A has requirements, code, and some unit tests to prove the code does what you wanted it to.  Why are we talking about project B or adding coverage for project A requirements outside project A?

[bokorpet]

@Jeff: because there may be a dependency between A and B such that if B is changed, the unit tests in A may not be PASSED any longer. Of course, I can open A and check manually but what if I have tens of dependencies that I don't want to check one-by-one. That's why, I thought, one can auto-populate the tests of dependent projects and automatically re-execute them in a remote project.

@Chris: I'll try to reproduce the scenario in a dummy project.

Thanks,

Peter