Jump to content

JoeDG

Members
  • Content Count

    4
  • Joined

  • Last visited

  • Days Won

    1

JoeDG last won the day on November 3 2011

JoeDG had the most liked content!

Community Reputation

1 Neutral
  1. Thanks, Omar and Jim. Jim, I think you're probably right: I think the problem is twofold: 1) I need to be just testing the public interface to the library and 2) The public methods are overly complex, such that their private components really *need* to be tested individually. I probably need to focus my efforts on refining my object model and then my testing strategy. I'm still pretty wet behind the ears regarding TDD, and software testing in general... I'm still trying to orient myself and get a basic understanding. Maybe with a few more course corrections, I'll begin to feel like I'm accomplishing something and not just wasting time. Thanks guys, for providing this awesome tool! -Joe
  2. 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
  3. I'd like to write tests for some VIs that are inside a LabVIEW Project Library. The VIs are privately scoped, so in order to test these, I need to place the test case inside the Library. From what I can tell, VI tester does not "see" the test if the test case is located inside a Library. If I move it out of the library into My Computer, and save all, the tests show up in VI Tester, but of course they are broken because they contain privately scoped VIs. How should I go about testing privately scoped VIs in Libraries? -Joe
  4. 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
×
×
  • Create New...

Important Information

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