Unit Testing... yay or nay?
-
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? :laugh:
Jeremy Falcon
-
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
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
-
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
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!
-
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
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.
-
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. :laugh:
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
-
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? :laugh:
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
-
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
-
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
-
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. :laugh:
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
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!" :laugh:
Mircea
-
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
-
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
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.
-
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
-
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
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 [^]
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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 [^]
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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
-
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 [^]
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Oh and please don't turn this into one of these dumb git-sucks type debates. I'm too old for that. :sigh:
Jeremy Falcon
-
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.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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.
-
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.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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.
-
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
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.
-
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. :laugh:
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
