Jump to content
JoeDG

How to create *simple* tests

Recommended Posts

I'm just getting started with VI Tester and TDD in general, and am loving the added feedback its provided my development efforts...

 

I'm struggling with how to create *simple* tests for VIs that are highly integrated and have complex dependencies. I use a lot of Action Engines, and am having difficulty writing simple tests for these types of VIs.

 

Here's a more specific example:

 

I have a Configuration AE (which handles reading and writing a config file) which calls a Debug AE (which handles logging and display of debug messages on the front panel) which calls a Front-Panel References AE (which stores references to FP controls, for when I need to change the UI).

 

How can I write a *simple* test to test the Configuration AE, without initializing the Debug AE, and FP References AE? And how can I initialize the FP References AE without making a "dummy" front panel that has the same controls as my user interface? We're approaching a giant test harness that looks very much like the actual application.

 

Is the problem not in learning how to write a simple test, but in my architecture? Are these kinds of dependent Action Engines poor programming technique? Or do I need to write a test harness that initializes all my AEs before I start testing them?

 

-Joe

Share this post


Link to post
Share on other sites

Hi Joe,

 

I'm just getting started with VI Tester and TDD in general, and am loving the added feedback its provided my development efforts...

 

I'm glad that you're having success getting started with VI Tester!

 

I'm struggling with how to create *simple* tests for VIs that are highly integrated and have complex dependencies. I use a lot of Action Engines, and am having difficulty writing simple tests for these types of VIs.

 

This is a simple question with a complex answer.

 

Low hanging fruit answer:

You can improve the testability of your Action Engines by having the Action Engines call a specific VI in each state (Initialize state can call an Initialize VI). This makes it easier to test the Action Engines for various conditions. Additionally, you can have the core logic encapsulated in such a way that the inputs (while they come from data stored in other Action Engines) are testable under test defined conditions. This is basically what Test Driven Development can help you achieve in terms of designing more testable systems.

 

Another way to solve the problem is to create mock objects that are used to simulate the Action Engine's dependencies (which are additional Action Engines). Ben Hysell wrote a good blog article about how to do this here. His example uses an object oriented architecture - in principle you can do this with an Action Engine hierarchy that is not OOP based, but OOP definitely makes it easier to swap in mock objects for the purpose of testing. In order to actually run using mock objects, I typically use a TestSuite to instantiate mock dependency objects that are used by the TestCase (which is testing a specific mock object).

 

You are correct that creating more tests can add to development overhead. We're actively working on ways to reduce this overhead, but some overhead will always exist. So it is worth it to evaluate where you want to spend the effort to create tests (i.e. Where do I get the most bang for my buck?).

 

Cheers,

Omar

Share this post


Link to post
Share on other sites

Thanks a lot, Omar, for your reply. This is exactly what I was looking for. And Ben's article is a great resource. I'll be digesting this and seeing what I can come up with along these lines. I also have a couple (former) Action Engines that I converted into LVOOP, so I can start to apply some of Ben's stuff more directly in those cases.

 

Thanks again,

Joe

 

Hi Joe,

 

 

 

I'm glad that you're having success getting started with VI Tester!

 

 

 

This is a simple question with a complex answer.

 

Low hanging fruit answer:

You can improve the testability of your Action Engines by having the Action Engines call a specific VI in each state (Initialize state can call an Initialize VI). This makes it easier to test the Action Engines for various conditions. Additionally, you can have the core logic encapsulated in such a way that the inputs (while they come from data stored in other Action Engines) are testable under test defined conditions. This is basically what Test Driven Development can help you achieve in terms of designing more testable systems.

 

Another way to solve the problem is to create mock objects that are used to simulate the Action Engine's dependencies (which are additional Action Engines). Ben Hysell wrote a good blog article about how to do this here. His example uses an object oriented architecture - in principle you can do this with an Action Engine hierarchy that is not OOP based, but OOP definitely makes it easier to swap in mock objects for the purpose of testing. In order to actually run using mock objects, I typically use a TestSuite to instantiate mock dependency objects that are used by the TestCase (which is testing a specific mock object).

 

You are correct that creating more tests can add to development overhead. We're actively working on ways to reduce this overhead, but some overhead will always exist. So it is worth it to evaluate where you want to spend the effort to create tests (i.e. Where do I get the most bang for my buck?).

 

Cheers,

Omar

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.