|
at least in the United States
4/20/2024
backward is
4/20/2024
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
And a proper 2024-04-20 as per international standard?
|
|
|
|
|
Obviously it doesn't work, which is why I specified US.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
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 2 days ago.
|
|
|
|
|
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 2 days ago.
|
|
|
|
|
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.
|
|
|
|
|
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 yesterday.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
