|
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
modified 20-Apr-24 12:19pm.
|
|
|
|
|
No I don't Unit Test but I QA to nth degree. I find that the kind of apps I write are not easy to Unit Test and the effort to learn and then to implement is not worth my time.
Maybe that's why it takes forever for me to release an app.
Definition of a burocrate; Delegate, Take Credit, shift blame.
PartsBin an Electronics Part Organizer - Release Version 1.3.1 JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Mike Hankey wrote: I QA to nth degree.
Tru dat. A dev should be the first step in QA. Like sometimes you gotta wonder... did you even run your code bro? 
Jeremy Falcon
|
|
|
|
|
I'm a one-man-shop so any QA hasta be done by moi. *PartsBin - An Elctronic Parts Organizer[^]
I also use the app so as I find bugs they get fixed quickly. Working on a new version now, so QA in progress. 
*Shameless plug
Definition of a burocrate; Delegate, Take Credit, shift blame.
PartsBin an Electronics Part Organizer - Release Version 1.3.1 JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Nice man. The app looks pretty cool.
Jeremy Falcon
|
|
|
|
|
Thanks for the kind words.
Definition of a burocrate; Delegate, Take Credit, shift blame.
PartsBin an Electronics Part Organizer - Release Version 1.3.1 JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
I am a fan of unit testing. So much that I wrote my own framework that I described in an article here. However I don't believe in TDD (I also wrote about that in a short blog post).
I call my strategy "Test Assisted Design"(TAD). Sometimes I write tests while I develop a piece of code because it's easier to verify just a small part instead of waiting to the very end. Most of these tests get discarded when the project is finished as they don't make much sense for a finished product. Other times I write tests in response to a bug report and I want to reproduce the bug and investigate. I never found myself writing tests in advance of the code itself as I understand you should do with TDD.
Mircea
|
|
|
|
|
Mircea Neacsu wrote: I am a fan of unit testing. So much that I wrote my own framework that I described in an article here.
Noice. Same here. It's like the more you do it, the more you see the usefulness. Kinda like eating your veggies.
Mircea Neacsu wrote: Sometimes I write tests while I develop a piece of code because it's easier to verify just a small part instead of waiting to the very end.
Same. Although, I don't use Jest or a testing framework for the temp/intermediary stuff. In the JS/TS world, I'd just pop open a JSFiddle or use a Node immediate window to test stuff. If the code does that I think it will, it makes it way into the routine that I'll eventually unit test for real. Those will hang around though.
Mircea Neacsu wrote: Most of these tests get discarded when the project is finished as they don't make much sense for a finished product.
Just the temp ones though right? You still keep the non-temp ones? I know for me, probably the best non-obvious reason to keep the non-temp ones is being able to automate finding out when someone breaks your code.
Mircea Neacsu wrote: I never found myself writing tests in advance of the code itself as I understand you should do with TDD.
Same
Jeremy Falcon
modified 20-Apr-24 13:35pm.
|
|
|
|
|
Jeremy Falcon wrote: Just the temp ones though right? You still keep the non-temp ones?
Indeed; a lot of those are for corner/limit cases that would be hard to verify from outside.
Jeremy Falcon wrote: being able to automate finding out when someone breaks your code.
AKA regression testing. Conversation overheard at work: "if you touch my code again, I'll break your π hand!" 
Mircea
|
|
|
|
|
No, but I am a hobbyist so my opinion probably doesnβt count for much. I just have the feeling that if you unit test then you end up writing the code to the test.
Reminds me of years ago there was a bad code contest on another web site. The idea was to write a bad calculator app that had to pass a predefined test.
One of the entries was so bad that no mater what numbers were entered into the calculator, the output was exactly what the unit test expected. But if anything else was entered it did not work at all. But as far as the unit testing was concerned, the app worked perfectly.
Within you lies the power for good - Use it!
|
|
|
|
|
Sup sup PJ, long time no type.
PJ Arends wrote: I just have the feeling that if you unit test then you end up writing the code to the test.
100%. Unit testing is like an art just like programming itself. And you do end up writing some extra code to test, and it takes more time, but it's sooooooooo worth it. Especially in terms of automating reports on code breaking, etc. It's like this, you're gonna spend the time one way or another... time writing good tests or time trying to figure out some crazy bug you have no idea about. Not to say testing will eliminate that, but it sure does help weed out the silly ones.
PJ Arends wrote: But if anything else was entered it did not work at all. But as far as the unit testing was concerned, the app worked perfectly.
Fo sho. That's what turned me off of it for so long. No different than using a pointer ya know. A pointer can speed up your application. Can also give it a segfault. The coder in question just wasn't too skilled at writing tests most likely.
Jeremy Falcon
|
|
|
|
|
Nay, we tried it for a while, but our code is changing so rapidly that maintaining the unit tests proved to be a daunting task for our small team of developers.
But it might be fine if you have enough developers to maintain the tests and your code base is not changing too rapidly.
|
|
|
|
|
Funny how experience can be different. For me, unit tests speed up changing code.
|
|
|
|
|
It's also a question of discipline I think, or better the lack of it in our company.
|
|
|
|
|
Especially when you need to modify something that hasn't been touched in years. Even if you wrote the code.
I write unit tests to make sure that other people don't break the code that I wrote.
|
|
|
|
|
I have never written Unit Tests per se.
I found the way that works for me was to use small apps to test functionality as I develope it, once I am happy with the results I integrate it in the real project.
Once the real project get to a stage, then I test functionality as soon as it makes sense, when parts get ended.
When ended, I play a couple of days with the debug version before compiling to release and play again for a couple of days.
Then I deliver.
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.
|
|
|
|
|
Come to the dark side Nelek... come... (evil smiley)
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Come to the dark side Nelek... come... (evil smiley)
I would, but I am too lazy and procrastinator to do it now.
Maybe tomorrow?
Jeremy Falcon wrote: (evil smiley)
Something like π this?
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: I would, but I am too lazy and procrastinator to do it now.
Thanks for being honest, buddy. This is why we get along.
Nelek wrote: Something like π this?
Yes!!!! 
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Thanks for being honest, buddy.  This is why we get along.
This was a bit joke and a bit truth. You can read the reality a couple of messages below in my answer to haughtonomous[^].
Jeremy Falcon wrote: Yes!!!! 
Win+"." = π€―
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.
modified 22-Apr-24 6:26am.
|
|
|
|
|
Nelek wrote: You can read the reality a couple of messages below in my answer to haughtonomous[^].
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 tests come into their own when part of the build process. Write some code, check it into source control, the test suite is launched and a short time later when the suite of tests has completed you see what you've just broken, and fix it plus adding a new test to ensure that doesn't happen again. Trust me if your application/library/whatever is non-trivial, it saves a huge amount of time and much annoyance and embarrassment when a new release bounces back.
It helps if you think of the tests as part of the coding work, written as the coding progresses, not a dispensible add on afterwards. In fact, sometimes it was the writing of a test that helped me realise I had made a mistake in the code.
In my experience it was always the less experienced, less diligent, over hasty developers who rebelled against it (not to mention the few who thought they were too clever for their work to need testing, too sexy for their shirt, in fact). And of course the poor quality of their output was reflected in their reputation in the team/business.
|
|
|
|
|
haughtonomous wrote: In my experience it was always the less experienced, less diligent, over hasty developers who rebelled against it (not to mention the few who thought they were too clever for their work to need testing, too sexy for their shirt, in fact).
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.
When I came back to high level languages, I had to learn C#, WPF and the style of my senior, plus full responsibility on the PLCs interacting with the software. I know about the different Testing Trends, but being honest, I didn't feel like needing them that much.
It might give me a bad surprise somewhen? for sure.
Has it until now? Not once
Will I learn it after a bad situation? very probably.
Am I going to learn it right now? no, I have better things to do with my time.
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: 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.
Nelek wrote: Will I learn it after a bad situation? very probably.
That's what it took for me.
Jeremy Falcon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
