Unit Testing... yay or nay?
-
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 always write tests for the small components in the code (aka unit tests) for two reasons: 1. 1 day of writing unit tests saves me a week of looking for bugs in the small crevices of a larger project 2. unit tests describe the behaviour of the component, so they double as documentation Also, since I have mostly worked at small companies there is usually nobody to double check my code. So testing is fundamental to avoid big mistakes.
-
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
It's a "yay" from me! However I'm a bigger fan of integration testing, whereby one can test the full functionality of a system or part of it. Not a believer in TDD.
-
Ravi Bhavnani wrote:
Yay for unit tests, because I like to sleep easy at night. :)
Preach brother.
Ravi Bhavnani wrote:
Our DOD requires the creation/modification of unit tests when new functionality is implemented and existing functionality modified.
What's DOD mean? I think Dept of Defense when I hear that. Just curious.
Ravi Bhavnani wrote:
We don't yet do TDD but are in the process of implementing integration test projects that would make it easy for devs to write the test before writing the code.
Be curious to know how it goes. I've never done full blown TDD (I'm stubborn), but would love to hear a use case about it.
Ravi Bhavnani wrote:
Thankfully all our dev managers are ex-developers.
The best ones are, buddy. :thumbsup:
Jeremy Falcon
Jeremy Falcon wrote:
What's DOD mean? I think Dept of Defense when I hear that. Just curious.
Design or Death? (The Software Engineer's equivalent of Publish or Perish... :) )
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:
One can only test a trigonometric function by comparing its results to the results of another implementation coded using a different approximation.
There's nothing preventing you from unit testing that. It's call mocking and just about every testing framework supports that. Testing approximations with even random values is completely doable in just about any testing framework.
Daniel Pfeffer wrote:
One can perform spot checks by comparing the results to known result calculated by another implementation, but that is hardly an exhaustive test of one's implementation.
There's always more code to write a unit test even if you're testing how to cross the street with grandma. That's not the point. The point is, it's worth it. And tests are an art just like software development, it's as exhaustive as you make it. Just because I don't know trig, doesn't mean I don't know things like cryptography and randomness. You can test that. Promise. But, let's pretend you can't test that one tiny part. Just for the sake of argument. You can still test 80-90% of the rest of the application. Edit: Btw, I hope this post didn't come across as sour man. I never know these days, and well most online chats are... you know. :~
Jeremy Falcon
I sit corrected.
Jeremy Falcon wrote:
Btw, I hope this post didn't come across as sour man.
Not at all. We're having a civilised debate, a rarity on the Internet these days... :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
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
The best use of unit-testing I've seen (ie. admired, admittedly from a distance thus far) is to create a test that breaks in a meaningful way (when fixing a bug, it tickles the bug and fails ... or when adding a feature, it tries to perform the actions that are not yet implemented). Then, 'fixing the bug' or 'implementing the feature' is 'done' when your test passes. The test lingers on ... because it continues to pass, you know that your latest changes didn't take other parts of your code backward. A great example of this discipline in action is the main dev of jOOQ (Github link)[^] ... he pretty much doesn't start a bit of new code without an issue and a failing test. 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.
-
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.
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.
-
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
Jeremy you are spot on; as the learned say: the more you know, the more you realise how much you have yet to learn. And the converse, of course.
-
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.
That's not an argument against writing tests, it's merely pointing out that some functions need to be tested exhaustively to be completely confident in their correctness, which may be impractical.
-
The best use of unit-testing I've seen (ie. admired, admittedly from a distance thus far) is to create a test that breaks in a meaningful way (when fixing a bug, it tickles the bug and fails ... or when adding a feature, it tries to perform the actions that are not yet implemented). Then, 'fixing the bug' or 'implementing the feature' is 'done' when your test passes. The test lingers on ... because it continues to pass, you know that your latest changes didn't take other parts of your code backward. A great example of this discipline in action is the main dev of jOOQ (Github link)[^] ... he pretty much doesn't start a bit of new code without an issue and a failing test. 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.
That's just TDD, isn't it? 😉
-
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 would, but I am too lazy and procrastinator to do it now.
Thanks for being honest, buddy. :laugh: :laugh: :laugh: This is why we get along.
Nelek wrote:
Something like 😈 this?
Yes!!!! :omg:
Jeremy Falcon
Jeremy Falcon wrote:
Thanks for being honest, buddy. :laugh: :laugh: :laugh: 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!!!! :OMG:
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.
-
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 Test, but I don't "TDD Unit Test". While I develop a piece of functionality, I repeatedly exercise the code I'm working on, as I write it. If at any point, it fails to compile, or shows signs of not "processing" some inputs correctly, I'll stop and fully debug everything, until it is working correctly once again. My testing can take many forms, but often, if it's a runnable app, then I'll just make sure that "the app" is runnable at all times. If it's a stand alone library, or isolated bit of functionality, then I'll often build a small command line program along side of it, that I can use to "test run" the code, allowing me to do things in my regular debug loop way. Once I'm happy the code is good, I then move up to building some test code, that integrates the system with the larger project (Should that be required), or set up some kind of testing harness (If it's a stand alone system) that exercises it using real test inputs and data. I do not, mock out things like databases, external API's and all that jazz. If I have to connect to an external API, then I connect to an external API, and if that API is not yet available, then that bit of work simply does not get started until it is. I simply will not write test code that "pretends" to be something it is not. My final step is usually one of setting up, large scale integration testing if required, or some smaller integration style unit test if code has to be independently testable. The key here, is I will create these unit tests only AFTER I'm satisfied I have done everything possible in other ways to produce good code that does the job required of it. I'll then use the integration testing, to A) ensure that the code stays working as it should with it's dependents & B) ensure that data & input changes don't screw anything up.
-
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
Yes
-
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
Yes, but nothing formalized. None of this automated stuff the kids do these days. Frequently, when developing an SQL function (in SSMS), I'll add some calls to the function in a commented-out area so I can test it and remember what some of the known edge cases are. I wish there were a way to do that for C# in VS.
-
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
Started writing some Unit Testing year ago and found that with the services I develop, unit testing is futile. That said, I have my own extremely broad testing infrastructure that is constantly running JScript and PowerShell generated client requests against my servers, some of those requests intentionally contain client request errors that we've seen come from specific client types. If you are dealing with library functions and methods that have fairly simple input parameters, Unit Testing can be useful. When dealing with a client server model that takes a wide variety of complicated XML HTTP posts, from various vendors, all of whom implement specifications differently, not so much. Most of the problems would be caught somewhere else farther down the stack. That said, I have a variety of iOS clients to test with since Apple's developers excel at not following specifications, especially when it comes to return codes.
-
I always write tests for the small components in the code (aka unit tests) for two reasons: 1. 1 day of writing unit tests saves me a week of looking for bugs in the small crevices of a larger project 2. unit tests describe the behaviour of the component, so they double as documentation Also, since I have mostly worked at small companies there is usually nobody to double check my code. So testing is fundamental to avoid big mistakes.
Nelson Goncalves Oct2022 wrote:
Also, since I have mostly worked at small companies there is usually nobody to double check my code.
That's a good point. I've found some of my own silly bugs that way too.
Jeremy Falcon
-
It's a "yay" from me! However I'm a bigger fan of integration testing, whereby one can test the full functionality of a system or part of it. Not a believer in TDD.
Fo sho, both integration testing and unit testing should happen. Usually integration testing is done by QA though.
Jeremy Falcon
-
The best use of unit-testing I've seen (ie. admired, admittedly from a distance thus far) is to create a test that breaks in a meaningful way (when fixing a bug, it tickles the bug and fails ... or when adding a feature, it tries to perform the actions that are not yet implemented). Then, 'fixing the bug' or 'implementing the feature' is 'done' when your test passes. The test lingers on ... because it continues to pass, you know that your latest changes didn't take other parts of your code backward. A great example of this discipline in action is the main dev of jOOQ (Github link)[^] ... he pretty much doesn't start a bit of new code without an issue and a failing test. 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.
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
-
I Test, but I don't "TDD Unit Test". While I develop a piece of functionality, I repeatedly exercise the code I'm working on, as I write it. If at any point, it fails to compile, or shows signs of not "processing" some inputs correctly, I'll stop and fully debug everything, until it is working correctly once again. My testing can take many forms, but often, if it's a runnable app, then I'll just make sure that "the app" is runnable at all times. If it's a stand alone library, or isolated bit of functionality, then I'll often build a small command line program along side of it, that I can use to "test run" the code, allowing me to do things in my regular debug loop way. Once I'm happy the code is good, I then move up to building some test code, that integrates the system with the larger project (Should that be required), or set up some kind of testing harness (If it's a stand alone system) that exercises it using real test inputs and data. I do not, mock out things like databases, external API's and all that jazz. If I have to connect to an external API, then I connect to an external API, and if that API is not yet available, then that bit of work simply does not get started until it is. I simply will not write test code that "pretends" to be something it is not. My final step is usually one of setting up, large scale integration testing if required, or some smaller integration style unit test if code has to be independently testable. The key here, is I will create these unit tests only AFTER I'm satisfied I have done everything possible in other ways to produce good code that does the job required of it. I'll then use the integration testing, to A) ensure that the code stays working as it should with it's dependents & B) ensure that data & input changes don't screw anything up.
Peter Shaw wrote:
I Test, but I don't "TDD Unit Test".
Same. :thumbsup:
Peter Shaw wrote:
I do not, mock out things like databases, external API's and all that jazz. If I have to connect to an external API, then I connect to an external API, and if that API is not yet available, then that bit of work simply does not get started until it is. I simply will not write test code that "pretends" to be something it is not.
Technically, if you needed fake DB data that would be a fixture. But, a unit test shouldn't call a live resource. You can't do gated check-ins that way as it would take too long to run thousands of tests.
Peter Shaw wrote:
My final step is usually one of setting up, large scale integration testing if required, or some smaller integration style unit test if code has to be independently testable.
Fo sho man. It's a very important step. QA usually does that though unless it's a small team. For unit testing in particular that's all dev though.
Jeremy Falcon
-
Yes, but nothing formalized. None of this automated stuff the kids do these days. Frequently, when developing an SQL function (in SSMS), I'll add some calls to the function in a commented-out area so I can test it and remember what some of the known edge cases are. I wish there were a way to do that for C# in VS.
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