Open RodneyRichardson opened 3 years ago
This is a good suggestion. I'll add it into the 1.2.0.0 milestone, but it might be pushed to 1.3.0.0, depending on whether I or any contributor has time to look into this. I suggest we do this as a parameter (so it's global for all tests) to maintain backwards-compability. We should also skip the IsTimeoutEnabled
and just use MaxTestDuration
(default it will be T#0S
which means that there is no time-limit)
Duplicate of #54?
Duplicate of #54?
Yepp. Good that someone is awake. So many comments and issues now that I think I'm getting senile. I'll leave this open and close both this and #54 once this is implemented.
Sorry for raising a duplicate - I didn't know github had a Discussions section!
No problems. You're welcome to implement! Just don't forget to read the contribs.
Moved this to release 1.3.0.0.
@RodneyRichardson I've assigned this issue to you. If you feel you don't have the time to look into it, just un-assign yourself.
Edit: https://github.com/tcunit/TcUnit/blob/master/CONTRIBUTING.md
Sorry - I don't have time at the moment. This may be something that is easier to implement in v2 if you go for a different architecture (e.g. one test per FB).
Anyone else care to take a look into this?
Hi Jakob, I was looking into this issue and I think I can handle it but I saw that there is an open PR #159 and @stefanbesler added some cool features about time (like: duration, startTime etc.) in his code that might be useful for this issue. So I am pending for his PR to be merged.
I am also thinking of adding Async capability to TcUnit to be able to test FBs which have delays like TONs inside of them and user expect to have an output with some delay!
Hey @NoidMasha ! It's highly appreciated that you want to look into this. I've just bumped the discussion over at #159, and hopefully we'll manage to get that PR implemented as soon as possible. I agree it makes sense to wait for #159 to be merged first.
this feature is now added in PR #181
I find I'm adding a timer (TON) to each of my tests to ensure that they don't get into an infinite loop. This is only a problem when tests run over multiple cycles (which mine do as I'm executing SFC/state machines), and the condition for calling TEST_FINISHED() is never met.
Can we have global settings (e.g. IsTimeoutEnabled : BOOL, MaxTestDuration : TIME) that will automatically fail/finish a test when it takes longer than expected?
A nice to have would be the ability to override this for a specific test (using either an attribute, or additional parameters to TEST/TEST_ORDERED).