Controlling System Time in a Unit Test

[eabrace]

Is there any way to control the system time returned from Get Date/Time in Seconds when unit testing a VI?  The VI I am attempting to test is very simple, but the output of the VI is entirely dependent on the system clock.  (See attached image.)

If there isn't any way to control the system time in this example, is there a better way to go about unit testing this VI?

I am using LabVIEW 2017 if that makes a difference.

(This is my first time using the unit test framework in LabVIEW and I'm sort of learning as I go, so I apologize if the answer to this is obvious.  I asked another developer with more experience this same question before I came here to ask for help.  They found the question very interesting but had no idea how to resolve the issue.)

[eabrace]

I'm not seeing the attachment in my opening post, so let's try that again.

[equinshadox · Accepted solution]

Not exactly a unit test VI, but you could call the VI in a FOR loop, and input an array of different time you want to test with.  Right-click the timestamp wire and Create Constant.  You can then build an array of these, each element of which you can edit the exact time.

Would this structure be helpful?

[eabrace]

I think I managed to come up with a workaround, but I'm not entirely comfortable with it because it requires referencing a global variable.

If I place the Get Time call inside a case structure, I can make the method of getting the time conditional.  Using a global variable (let's make it an enum and call it "EXECUTION") that indicates whether the software is being executed normally or as part of a unit test.  If EXECUTION is set to EXECUTE_UNIT_TEST, the time is read from the control.  If EXECUTION is set to anything else, the time is read using the Get Time call.

I can then manipulate the value of EXECUTION and the new time control in the unit test.

I just have to make sure that EXECUTION is properly initialized at startup so that there's no way to accidentally read the time from that control during normal operation instead of getting the time from the system.

[tyk007 · Accepted solution]

When faced with the same question some time ago, I did what I normally do in this type of situation where I have no control - I implemented an abstraction around the problem. My abstraction method of choice was encapsulating the logic of getting "Now" and utilizing dynamic dispatch to provide alternate implementations.

I created a DateTimeProvider class with a dynamic dispatch method (I called it "Now") that returned a TimeStamp. The default implementation was a wrapper around the usual LabVIEW Get node. I then created a child class that provided an alternate implementation of "Now" but always returned a pre-configured TimeStamp.Whoever create this child object would be responsible for setting this value.

My calling code (the code I was planning on testing) would require an instance of the DateTimeProvider class in order to function. It would internally call that "Now" method whenever it needed. If I provided a parent object, that internal code will get actual Now as a TimeStamp. If I provided a pre-configured child object, it would get the pre-configured value every time.

I also created another child class version that returned a TimeStamp from on a pre-configured array (incrementally and with roll-over) for cases where the code I was testing would perform multiple executions of the "Now" method.

[eabrace]

---

@tyk007 wrote:

When faced with the same question some time ago, I did what I normally do in this type of situation where I have no control - I implemented an abstraction around the problem. My abstraction method of choice was encapsulating the logic of getting "Now" and utilizing dynamic dispatch to provide alternate implementations.

---

That sounds like it's probably a great way to approach this.  But while I understood the concept of what you're talking about, the "how to" is just a bit beyond my level of expertise in LabVIEW at this point in time.  If I can find some time in the development schedule to play around a bit with that idea, I'll have to see if I can work the details out.

Thanks for your suggestion.