Unit Testing... yay or nay?
-
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
One can only test a trigonometric function by comparing its results to the results of another implementation coded using a different approximation. The problem is that one has to write this additional implementation, at least doubling the work that must be performed. 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.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Yay for unit tests, because I like to sleep easy at night. :) Our DOD requires the creation/modification of unit tests when new functionality is implemented and existing functionality modified. 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. Note: IMHO best practices like these require the buy in of management. Thankfully all our dev managers are ex-developers. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
Note: IMHO best practices like these require the buy in of management. Thankfully all our dev managers are ex-developers.
Upvoted for this. Over the decades, I have tried many times to get better practices to be adopted in my places of employment. My attempts have failed, usually when the managers realized that it isn't a magic bullet, and that there is a learning curve for adoption.
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
Sometimes I am lazy and skip them - typically when I am not quite sure I have the main "flow" worked out. It gives a short term benefit not spending time on them, but of course that has to be paid later - so I do at least make sure to write decoupled code that I can easily add the test. If I am reasonable certain of the flow, I write the test along with the code (sometimes even before as TDD, but that is rare). It is often much faster to itterate over a code block in the test than running an application. And of course, when I do go back and write the tests I skipped I find a bug or two.... In general it works as an investment: loose an hour writing a test now, or waste a day at a later time due to lack of tests... Sometimes the hour now is worth more than the day in the future. It only becomes a problem if the cost of the day in the future isn't even considered when skipping the test.
-
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.
-
Sometimes I am lazy and skip them - typically when I am not quite sure I have the main "flow" worked out. It gives a short term benefit not spending time on them, but of course that has to be paid later - so I do at least make sure to write decoupled code that I can easily add the test. If I am reasonable certain of the flow, I write the test along with the code (sometimes even before as TDD, but that is rare). It is often much faster to itterate over a code block in the test than running an application. And of course, when I do go back and write the tests I skipped I find a bug or two.... In general it works as an investment: loose an hour writing a test now, or waste a day at a later time due to lack of tests... Sometimes the hour now is worth more than the day in the future. It only becomes a problem if the cost of the day in the future isn't even considered when skipping the test.
Same man. Not every piece of code is tested, but for the code I know that has to work correctly or else... it is.
Jeremy Falcon
-
Quote:
There's absolutely no reason a framework would prevent unit testing.
I wasn't talking about a framework preventing it. I was talking about testing the framework itself.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
I wasn't talking about a framework preventing it. I was talking about testing the framework itself.
I know. Try again. I also know it's clear this conversation isn't gonna go anywhere. You can't say "bruh I don't know it and I don't wanna use it just because". Which means, we're just wasting time here.
Jeremy Falcon
-
One can only test a trigonometric function by comparing its results to the results of another implementation coded using a different approximation. The problem is that one has to write this additional implementation, at least doubling the work that must be performed. 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.
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
-
Yay for unit tests, because I like to sleep easy at night. :) Our DOD requires the creation/modification of unit tests when new functionality is implemented and existing functionality modified. 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. Note: IMHO best practices like these require the buy in of management. Thankfully all our dev managers are ex-developers. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
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
-
Ravi Bhavnani wrote:
Note: IMHO best practices like these require the buy in of management. Thankfully all our dev managers are ex-developers.
Upvoted for this. Over the decades, I have tried many times to get better practices to be adopted in my places of employment. My attempts have failed, usually when the managers realized that it isn't a magic bullet, and that there is a learning curve for adoption.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
And I upvoted your upvote... because why not. :laugh:
Jeremy Falcon
-
Greg Utas wrote:
I wasn't talking about a framework preventing it. I was talking about testing the framework itself.
I know. Try again. I also know it's clear this conversation isn't gonna go anywhere. You can't say "bruh I don't know it and I don't wanna use it just because". Which means, we're just wasting time here.
Jeremy Falcon
If you develop a framework, you need to eat your own dog food. A cliche, I know. But building an application to test it uncovers not only bugs, but things that should be added or reworked to make developers' lives easier. We're undoubtedly wasting time here. You're not interested in any contrary opinions but just want to virtue signal.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
It's also a question of discipline I think, or better the lack of it in our company. :-\
-
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
DOD = "definition of done" as applied to a work item. Before a work item can be marked complete, we require that it be unit tested and documented (this applies more to APIs).
Jeremy Falcon wrote:
The best ones are, buddy.
Agreed. I've found this to be the case more at early stage companies, which are the only places I've worked at since 2000. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
DOD = "definition of done" as applied to a work item. Before a work item can be marked complete, we require that it be unit tested and documented (this applies more to APIs).
Jeremy Falcon wrote:
The best ones are, buddy.
Agreed. I've found this to be the case more at early stage companies, which are the only places I've worked at since 2000. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
DOD = "definition of done" as applied to a work item.
Oh crap. I should've figured that out. I need coffee. :laugh: :laugh: Thanks tho.
Ravi Bhavnani wrote:
I've found this to be the case more at early stage companies, which are the only places I've worked at since 2000.
I've been the enterprise world for a while, but I'm starting to think you're onto something. Need a change, might have to give that a go.
Jeremy Falcon
-
If you develop a framework, you need to eat your own dog food. A cliche, I know. But building an application to test it uncovers not only bugs, but things that should be added or reworked to make developers' lives easier. We're undoubtedly wasting time here. You're not interested in any contrary opinions but just want to virtue signal.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Stop with the insults Greg. You do not amuse nor impress me. Also, I never said to not write a consuming application. You assume. And, it's clear you cannot absorb my posts by virtue of not understanding what I said when you misunderstood "framework". So just stop. You don't know a thing about unit testing and you would rather devolve into trite narcissism and demonstrate your lack of maturity.
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 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.
