|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
