Jump to content

Test Driven Development


Recommended Posts

I've attempted TDD in Labview a few times over the years and believe it would be a huge benefit... if I could figure out how to do it effectively. There's one issue I keep running into--namely, doing TDD in most languages entails writing the test code before writing any of the functional code that will be tested. Problem is... we can't do that in Labview. I can't drop a non-existent method for a non-existent class on the test method's block diagram. So I have to create the class and method stub before I can make any significant progress on my test, which disrupts the TDD process and eliminates at least some of the advantages of doing TDD in the first place.

Is there anyone who feels like they have successfully implemented a TDD process for LV development, and if so, can you share some of the strategies you use to work around our inability to code to non-existent classes and methods?

Link to comment

Bad me. I neglected to mention I've been using JKI's VI Tester. I've tried NI's UTF but had some issues with being unable to remove tests from the project and it annoyed me.

Or create empty VIs and write your tests before coding them...

Yeah, that's what I've been doing. But before I create the vi I have to create the class, and sometimes the method will return other classes, which means I have to go create them too. I think there's a real benefit to focusing on high level behavior by writing tests first. What ends up happening is I have to stub out the entire design before I'm able to write any tests, and that drags me into thinking about implementation instead of high level behavior.

One of the ideas of TDD is to create a test, watch it fail, then implement enough code to make the test pass. I tried creating a generic test stub class and methods to use as filler while creating tests. That didn't work so well. It requires too much temporary code (to prevent compiler errors) that gets removed when the implementation is ready to be tested. I also don't really like the idea of editing the test to replace the generic stubs with the real code.

Unfortunately I don't really see a good solution here. I suppose dynamically calling the code being tested would work, but that doesn't sound like a very good idea. I guess I'll have to keep creating stubs of my production code and try not to think about implementation.

Link to comment
Bad me. I neglected to mention I've been using JKI's VI Tester. I've tried NI's UTF but had some issues with being unable to remove tests from the project and it annoyed me.

Yeah, that's a nasty bug. Thankfully, the lvproj file is XML, so you can delete them in the file.

Link to comment

Yeah, that's a nasty bug. Thankfully, the lvproj file is XML, so you can delete them in the file.

If you remember to do it before opening the project. (I usually didn't...)

I get the impression VIE uses the UTF. In your opinion, does the UTF work well for testing object oriented code? I get the feeling UTF is better suited to testing procedural-based vis and JKI's VIT is better for testing objects. (Seems to me the NI and JKI should swap names of their unit testing tools. :D )

Link to comment
  • 2 weeks later...

I just posted in my NI thread a link to your post. Let's see if we can get someone to revisit this issue, track it down and get it fixed :)

Sorry for the highjacking... but just a note to say that it seems this issue has gone away in LabVIEW 2011 which is good news. And whether others can confirm this.

Link to comment

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.

×
×
  • Create New...

Important Information

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