Popular Post Daklu Posted June 16, 2011 Popular Post Report Share Posted June 16, 2011 I've used VI Tester (and NI's Unit Tester Framework) in the past, mostly to explore what they can do and how I can use them to improve my normal workflow. I've never been in a situation where I've *needed* to use it to get the job done--until now. I'm currently working on a motion-vision system where I'm dealing with 8 different frames of reference. Needless to say, the bookkeeping has been dizzying. Changes to one reference frame has a ripple effect through to the dependent reference frames. After spending several hours last week trying to sort out exactly how a change I had made broke the rest of my code and realizing I couldn't keep it all in my head at once, I decided to pull in VI Tester. Over the last several days I built 50+ unit tests to test the key transformation algorithms I have been using. My code was changing a lot so I probably spent more time writing and editing my test cases as I did writing production code. With deadlines looming I had to force myself to keep the unit tests up to date instead of abandoning them. In the end I was able to get the algorithms right with at least 6 hours to spare. I can't emphasize enough how valuable it was to make a change, run the tests, and get instant feedback on what effects the change had on the rest of the system. Understanding the benefits of unit testing is one thing--experiencing the benefits of unit testing is a whole 'nother feeling. Thank you JKI! 5 Quote Link to comment
Omar Mussa Posted June 17, 2011 Report Share Posted June 17, 2011 Understanding the benefits of unit testing is one thing--experiencing the benefits of unit testing is a whole 'nother feeling. Even internally at JKI, every few months someone says "wow, unit testing really saved me on xyz". I'm glad that you're getting some value out of your time investment! Thank you JKI! Thank you too! Keep on feeding us suggestions on how to improve VI Tester as well, we're definitely listening 2 Quote Link to comment
Daklu Posted June 17, 2011 Author Report Share Posted June 17, 2011 I'm glad that you're getting some value out of your time investment! Me too... but to be honest I'm more grateful for the time *you* invested in creating and releasing an awesome tool. I'm sure my investment was a pittance compared to yours. I did experience one inconvenient issue. After opening VIT, running some tests, and closing it, opening it again would cause an insane object error and LV would exit. I had to close the project and reopen it before starting VIT again. This is with LV9 sp1, Win7, and the latest version of VIT. It could be part of LV's object growing pains or something unique in my environment. I haven't had time to investigate the error at all and while inconvenient, it wasn't a big enough problem to prevent me from using the tool. One minor wish--I use the project dependencies folder a lot. Is it possible to wrap all those dependencies in a library? Quote Link to comment
Omar Mussa Posted June 17, 2011 Report Share Posted June 17, 2011 One minor wish--I use the project dependencies folder a lot. Is it possible to wrap all those dependencies in a library? Wow, I didn't know that you could use the dependencies folder for something useful. I use it only as a sort of garbage collector of things that I don't care about that happen to be in my project (I thought that was all it could do). How do you use the dependencies folder? (Also - yes I can look into wrapping all dependencies in a library). Quote Link to comment
Daklu Posted June 17, 2011 Author Report Share Posted June 17, 2011 Wow, I didn't know that you could use the dependencies folder for something useful. Sure... to figure out what my project is still dependent on. Mostly I use it for project maintenance when I'm refactoring and cleaning out dead code. During development I end up with a lot of vis (and classes and libraries to a lesser extent) that I used for preliminary work but have since discarded as the application evolves. I don't want to delete them from the repository or my hard drive unless I'm sure there aren't any lingering dependencies. Right-click, remove from project, check the dependencies folder to see if it showed up there. It's really useful when trying to disentangle someone else's code to exact a bit of useful functionality, or when replacing one library with a functionally similar library. (Say... switching from LapDog Message Library v1 to LapDog.Messaging v2.) I've also used it in the past when I've had private packages I've deployed using VIPM but haven't created palettes for. I don't really want them to be part of the project, but I do need them to be accessable. Quote Link to comment
Daryl Posted July 13, 2011 Report Share Posted July 13, 2011 Sure... to figure out what my project is still dependent on. Mostly I use it for project maintenance when I'm refactoring and cleaning out dead code. During development I end up with a lot of vis (and classes and libraries to a lesser extent) that I used for preliminary work but have since discarded as the application evolves. I don't want to delete them from the repository or my hard drive unless I'm sure there aren't any lingering dependencies. Right-click, remove from project, check the dependencies folder to see if it showed up there. It's really useful when trying to disentangle someone else's code to exact a bit of useful functionality, or when replacing one library with a functionally similar library. (Say... switching from LapDog Message Library v1 to LapDog.Messaging v2.) I've also used it in the past when I've had private packages I've deployed using VIPM but haven't created palettes for. I don't really want them to be part of the project, but I do need them to be accessable. Wow, thats a great tip!! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.