Unit Test Framework Year

[FireFist-Redhawk]

At my facility, we've never done any software unit testing that I know of, never even heard the phrase mentioned by my boss. So I'd like to delve into it to understand its business value. I'm going to start with Unit Test Framework because it's 1st party and ISO 9001 compliant. My main question is, if I develop in 2017 do I need UTF 2017? It honestly feels like a silly question to ask, but oh well. 

Somewhat related other thing. Another reason I want to get into unit testing is because a lot of my database VIs look like shown. This can be nice if you want to be able to run each one independently to say get a single test log's data, and I do occasionally find myself running one by itself for that or some other reason. But of course the main reason they were set up this way is so that each VI can be tested by itself. It is an extra two case structures and two functions added to every VI though. Is it bad practice to set them up like that?

Any other gotchas or personal experiences with UTF or unit testing in general that anyone would wanna share? It seems like it's meant to test the lower-level VIs and once you get to a certain level (or any GUI VIs), the onus of software validation is again on the developer. As always, any input is appreciated.

Spoiler

[Mark_Yedinak]

I personally don't like this approach. When testing your calls in the UTF, the open/close will be in the setup/teardown of the UTF. If you want to run your calls stand alone, create a test/utility application which gives you this capability. Why burden all of your code with what is essentially dead code for most of its uses?

[FireFist-Redhawk]

The guy who trained me had them set up that way (down to the weird casing of the case structure diagram labels), and so I've just always used it. I'm looking into better practices now though.

[Mark_Yedinak]

---

@FireFist-Redhawk wrote:

The guy who trained me had them set up that way (down to the weird casing of the case structure diagram labels), and so I've just always used it. I'm looking into better practices now though.

---

Well, it certainly isn't the worst code I have seen. I just try to keep things simple and not over burden VIs with extra functionality. In this case, the open/close of the DB should be handled at the application level. Generally you would only want to open the connection once and leave it open while your are running. Putting code in for convenience purposes only just adds complexity and overhead to your VIs. If you want to get some good tips for good coding practices, check out the SOLID principles of OOP. The general principles can be applied to non-OOP code as well.