Unit Testing... yay or nay?
-
PIEBALDconsult wrote:
I wish there were a way to do that for C# in VS.
Doesn't VS offer some sorta doxygen style comments? That's a great idea and I do the same in Node with jsdoc style comments. For VSCode at least, it has the bonus of also showing the example uses or edge cases via intellisense too.
Jeremy Falcon
I think it's things which get executed at compile time, but I would want to have the ability to execute ad-hoc tests whenever I like.
-
So I got to thinking... dangerous I know. But curious to know how many peeps unit test their code. IMO _some_ arguments can be made for not doing BDD/functional testing, but unit testing is hard to say "that's a bad thing" for. I know for me, I used to loathe the concept of unit testing. It was like just as boring and tedious as documentation (that nobody ever reads). That was right up until it saved my bacon a few times. Prior to that experience, I've only ever seen devs write crappy tests that were useless and thus considered it a feel-good exercise for a green checkmark. Didn't really think about the dev just being lousy at writing tests. Still don't do TDD though, but fo sho do unit tests after development. Anyone here big into unit testing? Yay? Nay? Has cooties?
Jeremy Falcon
Unit testing: very much yay. I've been doing unit testing steadily since about 1999. I have my own simple unit test driver. Tests are static member functions. It can all be statically linked with an executable. No tests enabled equals no overhead in size or time. The two places I've worked that did unit testing also had the highest code quality of the places I've worked. I've used a couple of open source frameworks for unit tests, but they seemed unnecessarily complicated to me, and it's annoying to have to separately compile test executables. Writing unit tests helps me wring out my designs and of course avoid regressions when I change things (which happens all the time).
-
Nelek wrote:
I have been more or less half my working life programing PLCs and Robots, you couldn't program tests like this in them, additionally every few projects (timeslot between a couple of weeks and some months) there were something new that I needed to learn quick to make the project, so I never cared to go out of scope with my time as I already had enough new staff to keep me busy / happy. That's why I got used to test in other ways, and believe me, I can be really nitpicky while testing.
Keep in mind, I don't know PLC programming, so there's a chance I'm talking out of my arse here... but would it be possible to at least treat the parts that interact with the hardware like a UI layer of sorts? If so, you can still test a logic layer irrespective of it's IO, etc.
Nelek wrote:
I didn't feel like needing them that much.
Can't blame ya man. I felt that way too for years. Didn't realize at the time though it's only because I've ever seen lousy tests written prior to that. It's more the fault of the dev though IMO. Like lousy tests are a waste of time that accomplish nothing. Good ones.. are... well... good. :laugh:
Nelek wrote:
Will I learn it after a bad situation? very probably.
That's what it took for me. :laugh: :laugh: :laugh:
Jeremy Falcon
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.0A a
BEBA b
AN c
= xBelieve 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:
You can read the reality a couple of messages below in my answer to haughtonomous[^].
:thumbsup:
Nelek wrote:
Win+"." = 🤯
Holy crap. Never knew that. 💯
Jeremy Falcon
Jeremy Falcon wrote:
Holy crap. Never knew that. 💯
The only wasted day is the day where you learn nothing new ;)
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.
-
Unit testing: very much yay. I've been doing unit testing steadily since about 1999. I have my own simple unit test driver. Tests are static member functions. It can all be statically linked with an executable. No tests enabled equals no overhead in size or time. The two places I've worked that did unit testing also had the highest code quality of the places I've worked. I've used a couple of open source frameworks for unit tests, but they seemed unnecessarily complicated to me, and it's annoying to have to separately compile test executables. Writing unit tests helps me wring out my designs and of course avoid regressions when I change things (which happens all the time).
SeattleC++ wrote:
I've been doing unit testing steadily since about 1999.
Noice. For me it's only been a few years, but the more I do it and the better I get at it, the less of a chance of ever turning back ya know.
SeattleC++ wrote:
and it's annoying to have to separately compile test executables
Oh yeah, that is one one of the caveats I faced in a C project once. The way I handled it was to have my overall build command just compile both. Probably harder to get away with that for C++, so cool idea.
Jeremy Falcon
-
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.0A a
BEBA b
AN c
= xBelieve 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
-
DT Bullock wrote:
Unit testing should absolutely not be used for things like double-checking that code does what the complier pretty much says it will. Less is more.
Compilers can't check logic errors. Not sure if that's what you meant or not.
Jeremy Falcon
OK, I was a little vague about that. I've seen people write tests that exercise getters/setters, behaviour from missing arguments, etc. In Java at least, a few good annotations takes care of all that rigmarole and you don't need to write tests for that stuff. But let's talk about tests which 'confirm expected behaviour'. I feel like this kind of test is a waste of time until we've encountered a non-expected behaviour that we want to squash and know that it stays squashed. Because 'the expected behaviour' is already a path we have trodden while developing/debugging, and obviously we wouldn't think we're done until it's behaving as expected already. But our oversights are the things we need to come back for and scaffold with some tests, because we're prone to overlooking some aspects of the state-space and need that support. It's about benefit vs bother in the end. You have to cherry-pick your testing opportunities and get on with making the code. IMHO.
-
That's just TDD, isn't it? 😉
Yeah, kinda. I feel it's less tedious/rigorous/exhaustive than TDD as I've seen it explained. I've seen TDD promoted as an iterative design aid: you don't know what you're doing exactly so you write a test which uses an imaginary API, then try to get the test working. Then you reflect a little more and adjust the test and write some more primary code. There are some benefits of this such as you've got only a very short departure from code that runs at all times. However the test *driven* nature of it doesn't sit well with me. I like to do as much up-front-design as I can: in my head, on paper, as formal requirements, whatever. In the Unit Testing I admire, it's more of a "there, I deliberately broke something, and when I'm done it won't be broken anymore". You're not so much testing for correctness or using it as a design process, as you're throwing spanners in your own gears and making your code cope. It now 'covers more ground' than it did previously
-
OK, I was a little vague about that. I've seen people write tests that exercise getters/setters, behaviour from missing arguments, etc. In Java at least, a few good annotations takes care of all that rigmarole and you don't need to write tests for that stuff. But let's talk about tests which 'confirm expected behaviour'. I feel like this kind of test is a waste of time until we've encountered a non-expected behaviour that we want to squash and know that it stays squashed. Because 'the expected behaviour' is already a path we have trodden while developing/debugging, and obviously we wouldn't think we're done until it's behaving as expected already. But our oversights are the things we need to come back for and scaffold with some tests, because we're prone to overlooking some aspects of the state-space and need that support. It's about benefit vs bother in the end. You have to cherry-pick your testing opportunities and get on with making the code. IMHO.
DT Bullock wrote:
I've seen people write tests that exercise getters/setters, behaviour from missing arguments, etc. In Java at least, a few good annotations takes care of all that rigmarole and you don't need to write tests for that stuff.
Well, with anything in life, it's hard to become good at something that one never learns to do or never learns to do well. The vast, vast majority of peeps in programming fall into that category. They can tell you what a byte is, but they can't tell you what a nibble is. For instance. Anyway, imagine trying to learn to ride a motorcycle from a book written by a crackhead deprived of sleep. That's what's being done here. :laugh: Just don't use the mediocrity from one situation as the sole means of analysis as you're limiting yourself to the lack of know-how from another. Test writing is the same as development. It's an art. So it's just a useless or as useful as you make it. Fo realz.
DT Bullock wrote:
It's about benefit vs bother in the end. You have to cherry-pick your testing opportunities and get on with making the code. IMHO.
Nah man. I promise it's more than that. I used to be turned off of testing for that reason too. But if I was being honest, I also didn't know anything about it at the time. If all the examples you've seen are crap then it gives that impression. Side note, as far as confirmation expectations only... if we're being real, even if that were the case that's still not a bad thing. You can handle the unexpected as well, but still. Also, the secondary benefit of making sure code isn't messed up that _used_ to work... in an automated fashion is a pretty nice benefit from confirming expectations.
Jeremy Falcon
-
DT Bullock wrote:
I've seen people write tests that exercise getters/setters, behaviour from missing arguments, etc. In Java at least, a few good annotations takes care of all that rigmarole and you don't need to write tests for that stuff.
Well, with anything in life, it's hard to become good at something that one never learns to do or never learns to do well. The vast, vast majority of peeps in programming fall into that category. They can tell you what a byte is, but they can't tell you what a nibble is. For instance. Anyway, imagine trying to learn to ride a motorcycle from a book written by a crackhead deprived of sleep. That's what's being done here. :laugh: Just don't use the mediocrity from one situation as the sole means of analysis as you're limiting yourself to the lack of know-how from another. Test writing is the same as development. It's an art. So it's just a useless or as useful as you make it. Fo realz.
DT Bullock wrote:
It's about benefit vs bother in the end. You have to cherry-pick your testing opportunities and get on with making the code. IMHO.
Nah man. I promise it's more than that. I used to be turned off of testing for that reason too. But if I was being honest, I also didn't know anything about it at the time. If all the examples you've seen are crap then it gives that impression. Side note, as far as confirmation expectations only... if we're being real, even if that were the case that's still not a bad thing. You can handle the unexpected as well, but still. Also, the secondary benefit of making sure code isn't messed up that _used_ to work... in an automated fashion is a pretty nice benefit from confirming expectations.
Jeremy Falcon
Sure, I expect I will expand my use of unit testing in the future, do a good job of it, and reap the benefits.