Last week, JKI released VI Tester. To some, this might seem like an overnight development, but it is really the result of several years of internal development and eating our own dog food. This is something that's very important to us, and we do it with all our JKI Software products. In fact, the path to "productization" is a natural outgrowth of our normal development process at JKI. Generally, the process is:
- Identify a tool that we need for a project, but that doesn't already exist.
- Create the tool that we need, so we can work better or more efficiently.
- Share the tool among our team and use it on multiple projects.
- Improve the tool based on team/user feedback.
- Repeat steps 3 and 4 over time.
During this process, we continuously evaluate whether the tool is a candidate for a commercial product or whether it would be more appropriate for a community release (e.g. on JKI Labs).
Now, let's look more closely at how VI Tester evolved...
A few years ago, we identified the need to unit test our code -- primarily as a tool for ensuring quality for our JKI Software products like VIPM and EasyXML. Our customers depend on these products to perform reliably, and they're too complicated for us to test by hand. We also wanted to use an xUnit framework because this software testing architecture has proven to be a powerful tool in the software engineering world. Additionally, xUnit test frameworks have spawned Agile and Test-driven development processes that our company strives to replicate in LabVIEW. Since xUnit frameworks are object-oriented unit test frameworks, with the release of LVOOP we saw an opportunity to create a powerful tool to make our own lives easier, and our software more robust.
We started by reading a lot of unit testing books and articles. We studied the xUnit architecture and some reference implementations (like PyUnit). We thought about how the xUnit architecture would best be implemented using LabVIEW's by-value object-oriented paradigm. We built a prototype in LVOOP, added a basic GUI, and started using it in projects.
With the basic test designs in place, we had VI Tester working essentially as you see it today. However, sharing a tool requires hammering it into a form that makes it easy for other developers to use. We know that there is no better tool than VI Package Manager for LabVIEW tool distribution - so we built VI Tester into a package! This allowed our whole team to easily use VI Tester on several versions of LabVIEW and across multiple projects. In fact, we're even using VI Tester to run unit tests on VI Tester itself, to make sure it works the way we expect it to! (did we mention the dog food yet?)
Improving VI Tester means incorporating feedback from users to make the tool even better. As long as a tool remains internal, that feedback is limited to a handful of users. This has the positive effect of not overwhelming the development team when the product is immature. However, we really want all of JKI's tools to make an impact on the entire LabVIEW Ecosystem, so we are constantly looking for ways to help users help us. In the case of VI Tester, JKI Labs is the best way to let users benefit from VI Tester, and participate in making it better.
Repeating the process:
And now, we arrive at the present day. In reality, VI Tester has already been through many cycles of sharing / feedback / improvement thanks to our internal team and our private beta testers. But now, by releasing VI Tester on JKI Labs, we're making a statement: we think VI Tester is ready to help you improve the robustness of your software; and if it's not, we want to know how we need to improve it to make it useful to you. And in doing this, we want to facilitate the ongoing process of bringing high-quality software engineering practices to the world of LabVIEW development. Try out VI Tester, join the discussion on our forums, and stay tuned for more exciting blogs posts, examples, templates, and videos that will help you get the most out of VI Tester, and out of LabVIEW.