|
In PLC Programming you have a limited set of instructions, some more than in assembly. And you almost speak directly to the hardware.
For instance:
If (a == true)
{
return;
}
if ((b == true) && (c==false))
{
x = true;
}
In PLC that would be: ("i" for input register and "o" for 24 V / 0.5 A output register)
a = i0.0
b = i0.1
c = i0.2
x = o0.0
A a
BEB
A b
AN c
= x
Believe me when I say, you can't test like in high level.
Checking out boundaries or plausibility is something I have done too though, but the logic behind is pretty diffrerent as in Unit testing.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: Believe me when I say, you can't test like in high level.
I believe ya man. On the upside, you get cool points for going low level.
Nelek wrote: Checking out boundaries or plausibility is something I have done too though
Noice
Jeremy Falcon
|
|
|
|
|
I've hardly ever written a unit test. The few times I did, it was to test a complex, standalone function. Other than that, the test harness would have been far too much work. System and regression testing (automated) are where it's at. Where I worked, developers tested new features--code that they'd written, in many cases largely standalone--but almost always ran tests with their code integrated into the entire system.
A decade ago, Jim Coplien (one of the original C++ gurus) wrote a good article about this. It's fairly long, so scroll to the bottom for his recommendations if you don't have enough patience.
Why Most Unit Testing is Waste | PythonTest [^]
|
|
|
|
|
Greg Utas wrote: Other than that, the test harness would have been far too much work
Overlooking the "too much work" part... People that say that don't know unit testing. I can promise you that. Not sure what you define as harness, but if you mean setup, say for something data-driven, then mocking and fixtures are a thing. If anyone thinks they don't help alleviate any issues, then they don't know unit testing.
Greg Utas wrote: A decade ago, Jim Coplien (one of the original C++ gurus) wrote a good article about this. It's fairly long, so scroll to the bottom for his recommendations if you don't have enough patience.
Not trying to turn this into a debate, but you should know that titles don't mean jack to me. Don't care if they wrote an article or not or if he knows C++ or not. Doesn't mean that automatically qualifies him as the expert of all things ever created. I'm not coming at this from a n00b man; I'm just keeping it casual instead of preachy.
I can tell you this man, it's usually the people that know the least about a subject that have such strong opinions. Not always, but a lot times that's true.
Jeremy Falcon
|
|
|
|
|
Titles also mean nothing to me. The fact that I have some respect for Coplien is therefore telling.
Maybe unit tests work for you. I developed frameworks for most of my career. To test them, I developed applications that used them.
|
|
|
|
|
Greg Utas wrote: To test them, I developed applications that used them.
That has been my approach for long too, without programming frames but Apps instead.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Greg Utas wrote: Titles also mean nothing to me. The fact that I have some respect for Coplien is therefore telling.
Fair enough.
Greg Utas wrote: Maybe unit tests work for you. I developed frameworks for most of my career
There's absolutely no reason a framework would prevent unit testing. If you think that, and I swear I'm not trying to be mean, but you don't know unit testing. And that's ok... I don't know everything.
So, just say you don't wanna do it because you don't wanna do it. 
Jeremy Falcon
|
|
|
|
|
Quote: There's absolutely no reason a framework would prevent unit testing.
I wasn't talking about a framework preventing it. I was talking about testing the framework itself.
|
|
|
|
|
Greg Utas wrote: I wasn't talking about a framework preventing it. I was talking about testing the framework itself.
I know. Try again. I also know it's clear this conversation isn't gonna go anywhere. You can't say "bruh I don't know it and I don't wanna use it just because". Which means, we're just wasting time here.
Jeremy Falcon
|
|
|
|
|
If you develop a framework, you need to eat your own dog food. A cliche, I know. But building an application to test it uncovers not only bugs, but things that should be added or reworked to make developers' lives easier.
We're undoubtedly wasting time here. You're not interested in any contrary opinions but just want to virtue signal.
|
|
|
|
|
Stop with the insults Greg. You do not amuse nor impress me. Also, I never said to not write a consuming application. You assume. And, it's clear you cannot absorb my posts by virtue of not understanding what I said when you misunderstood "framework". So just stop. You don't know a thing about unit testing and you would rather devolve into trite narcissism and demonstrate your lack of maturity.
Jeremy Falcon
|
|
|
|
|
Jeremy you are spot on; as the learned say: the more you know, the more you realise how much you have yet to learn.
And the converse, of course.
|
|
|
|
|
haughtonomous wrote: And the converse, of course.
100% man. 
Jeremy Falcon
|
|
|
|
|
Oh and please don't turn this into one of these dumb git-sucks type debates. I'm too old for that. 
Jeremy Falcon
|
|
|
|
|
IMO, it only makes sense to do unit testing when the inputs & outputs from a function/module can be specified. To take a very simple case, testing the strlen() function in C:
- Input must be a non-null pointer
- Output must be a non-negative integer
- The (output)th character of the input is a null character.
- No null characters are to be found in the range [ 0 .. (output) ) of the input
In cases where the output is not easy to check (for example a trigonometric function), exhaustive testing is impractical. In this case, only very simple "sanity" tests can be performed.
In real-world code I usually try to test all boundary conditions, but don't try to perform exhaustive testing.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: IMO, it only makes sense to do unit testing when the inputs & outputs from a function/module can be specified.
Fo sho, that's actually a unit test. There other type of larger tests (functional tests) that get a bit more abstract, which one can make a case for or against. But, a unit test should test a very small unit. Typically that will equate to a routine, um... unless you have 5 page long functions.
Daniel Pfeffer wrote: In cases where the output is not easy to check (for example a trigonometric function), exhaustive testing is impractical. In this case, only very simple "sanity" tests can be performed.
Keep in mind, I don't know trig like at all... but most testing frameworks allow you to test all kinds of output. If by not being able to test trig you mean like a picture on the screen, you can even test that too whether it's against a fixture or something else. Or perhaps test the routine before it gets sent to a renderer than then also visually compare and so on. It's like riding a bike, the more you do it the mo' easy it becomes to test.
Jeremy Falcon
|
|
|
|
|
One can only test a trigonometric function by comparing its results to the results of another implementation coded using a different approximation. The problem is that one has to write this additional implementation, at least doubling the work that must be performed. One can perform spot checks by comparing the results to known result calculated by another implementation, but that is hardly an exhaustive test of one's implementation.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: One can only test a trigonometric function by comparing its results to the results of another implementation coded using a different approximation.
There's nothing preventing you from unit testing that. It's call mocking and just about every testing framework supports that. Testing approximations with even random values is completely doable in just about any testing framework.
Daniel Pfeffer wrote: One can perform spot checks by comparing the results to known result calculated by another implementation, but that is hardly an exhaustive test of one's implementation.
There's always more code to write a unit test even if you're testing how to cross the street with grandma. That's not the point. The point is, it's worth it. And tests are an art just like software development, it's as exhaustive as you make it. Just because I don't know trig, doesn't mean I don't know things like cryptography and randomness. You can test that. Promise.
But, let's pretend you can't test that one tiny part. Just for the sake of argument. You can still test 80-90% of the rest of the application.
Edit: Btw, I hope this post didn't come across as sour man. I never know these days, and well most online chats are... you know. 
Jeremy Falcon
modified yesterday.
|
|
|
|
|
I sit corrected.
Jeremy Falcon wrote: Btw, I hope this post didn't come across as sour man.
Not at all. We're having a civilised debate, a rarity on the Internet these days... 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
That's not an argument against writing tests, it's merely pointing out that some functions need to be tested exhaustively to be completely confident in their correctness, which may be impractical.
|
|
|
|
|
That was exactly my point.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Yay for unit tests, because I like to sleep easy at night.
Our DOD requires the creation/modification of unit tests when new functionality is implemented and existing functionality modified. We don't yet do TDD but are in the process of implementing integration test projects that would make it easy for devs to write the test before writing the code.
Note: IMHO best practices like these require the buy in of management. Thankfully all our dev managers are ex-developers.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: Note: IMHO best practices like these require the buy in of management. Thankfully all our dev managers are ex-developers.
Upvoted for this.
Over the decades, I have tried many times to get better practices to be adopted in my places of employment. My attempts have failed, usually when the managers realized that it isn't a magic bullet, and that there is a learning curve for adoption.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
And I upvoted your upvote... because why not.
Jeremy Falcon
|
|
|
|
|
Ravi Bhavnani wrote: Yay for unit tests, because I like to sleep easy at night. 
Preach brother.
Ravi Bhavnani wrote: Our DOD requires the creation/modification of unit tests when new functionality is implemented and existing functionality modified.
What's DOD mean? I think Dept of Defense when I hear that. Just curious.
Ravi Bhavnani wrote: We don't yet do TDD but are in the process of implementing integration test projects that would make it easy for devs to write the test before writing the code.
Be curious to know how it goes. I've never done full blown TDD (I'm stubborn), but would love to hear a use case about it.
Ravi Bhavnani wrote: Thankfully all our dev managers are ex-developers.
The best ones are, buddy. 
Jeremy Falcon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
