|
Unit testing tests for code that is primal and isn't the cause of problems. Test that the value I passed you is a bool.
What does cause problems are things like Excel cells that are missing or contains the wrong data. Data configurations that you did not plan/account for. Users that do things you did not think they would ever do. Exceptions you missed that blew up the app.
And lets not forget that you are writing test code to test your code. 
|
|
|
|
|
It sounds like what you do is exactly what unit testing is.
Perhaps some of the other parts of the Capitalized-Letter "Unit Testing" practices that might come to mind are
> keeping selected relevent unit test cases for reuse in either/both future development or qa builds.
> running the tests *automatically* against a shared build, especially during heavier development times, shared or otherwise.
I don't think these are truly new, but have become more widely recognized and adapted for practically any language. We used to do this stuff in COBOL.
Beware of when any programmer makes automating a test ritually - if it's automatic, there should be a reason for the test. Some people mistake statistics for quality. If a case doesn't make sense anymore get rid of the test(s).
What's great is there are so much shared knowledge and experience. Frameworks and suggested practices abound.
And if you don't happen to use a framework for it, there's really no issue, and it has just as much relevence.
Automating tests is essential to expediting refactoring code. It gives me some assurance that unexpected behaviors haven't popped up.
Some tests behave like functioning documentation to remind me in the future just how this thing works.
|
|
|
|
|
I used to be skeptical about unit testing and TDD/BDD. Mainly because it felt like it was too much work.
Then 2 things happened more or less simultaneously: I got to work on a huge code base that had a 85% unit test coverage and I saw this talk by Ian Cooper/[^]
The talk showed me how you can write unit tests that aren't tightly coupled to the implementation of your code, which makes them less brittle and only subject to change when your code has functional changes.
The big codebase showed me that it is much easier and less risky (and will therefore be done more often) to make bigger changes and/or refactorings when you know your unit test suite will yell at you when you make a mistake.
|
|
|
|
|
We code a extremely large enterprise program (multiple EXE's, multiple Windows services, etc.). We use automatic unit testing in only 2 places. Both of them are for complex calculations with a handful of inputs and outputs. There are billions of possible logic paths.
The unit tests included about a 1000 sets of inputs that covered common scenarios and edge cases.
That way if we had to fix the calculations, we knew that they still worked by just running the unit tests. These are not automatically run. Dev's just run them if they change the matching code.
We also use an automatic testing suite to test the program. There is a separate team that creates and maintains that suite. The Dev's never talk to them. I have no idea what they do or how they do it. It took 2+ years for them to get about 90% test coverage. We consider running this automatic test suite as smoke testing.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
I've been writing C/C++/C# professionally now for 30 years in the critical realm of industrial automation. I've never done formal unit testing. I write code carefully and deliberately, refactoring as necessary until it looks clean and efficient. I then run some tests to confirm the expected functionality - and then I move on. The key to success is following SOLID principles and not moving on until the code is clean and methods/variables are well named. A method that works will continue to work, and clean well-named code is easy to work with later.
|
|
|
|
|
I pretty much said the same. there is not much room for error in industrial automation. keeping the code clean without anything that can be ambiguous is always a solid direction.
like you know, it's almost impossible to simulate all the analog and digital signals that happen in the real world. writing unit tests for that would dwarf the original code 
I do miss working in industrial automation, I liked the challenges that came from it. just didn't like the companies or people I worked with there, too many hours away from home, too little pay, and too much stress being the sole dev to do it all.
|
|
|
|
|
I love unit testing. When I'm not working with a testing framework, every class has a static method for testing (static, so it isn't linked into the executable unless you call tests). I test things when I change things.
The two projects I worked on that had the lowest defect density both had good unit tests and a desire to make them better. Did I mention that I love unit testing?
|
|
|
|
|
I've always been a single dev, once or twice working with another dev at jobs. I've never bothered with Unit Testing (when it started to become popular), because of the nature of the embedded or control software made it almost impossible to simulate real world situations. the code had to be correct also because of the litigation that could happen if something is even a little off and you destroy product.
Although I'm not building that stuff as much anymore, I still go by my old habits of building code and test running it early as possible. some more complex things will get a temporary project to test the code and once I'm happy I'll integrate it into the main project. I rarely have bug issues and still have software out there running since 2001-ish.
this is my first job using SQL that I've never needed before in my previous jobs, but I still find when making stored procedures or complex views that I follow my normal build, test, and expand until the final SPROC is completed. It's nice because it's always a testable 'unit' to verify results separate from the software logic.
this place I'm working for now had so much embedded inline SQL in the legacy code, so It's almost impossible to test out separately from the program logic, so it's all getting replaced slowly.
tldr; I'm old and stubborn, and my process has been working great for me forever, I see no need to use Unit Testing at this point.
|
|
|
|
|
Uhhhh, you have already embraced unit testing. Your static class *is* a unit test. Otherwise known as a device to keep programmers sane(ish).
It doesn't integrate with frameworks or IDE integration, but it's a unit test.
|
|
|
|
|
It doesn't matter how you do Unit Testing as long as it is done legitimately.
I always do my own Unit Testing using the old fashioned technique of testing all the functions in my applications by hand.
The result is that I have practically never had a deployment with any serious issues. And the one or two times that did happen, the issues were quickly resolved.
You do not need a tool to do quality testing, just common sense.
Besides, if you do database, intensive application development, there is no real way to implement a tool such as NUnit since the only reliable tests are that a database call did not yield an access\update error and if the data returned/updated was done properly...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I reluctantly accepted unit tests, and now I think they are fantastic. Can't tell you how many times unit tests caught breaking changes for our team.
Also, when developing some heavy duty optimizers it was great being able to test the code without having to fire up the UI and submit a job etc. Just debug the unit test to see where things went wrong.
I am guilty of writing a lot of integration tests masquerading as unit tests. But then, working on a legacy app with a lot of dependencies, it's nice to be able to test those with confidence, too.
Creating the first test is hard, but once it's done the rest just seem to flow. Now that a lot of classes have unit tests the barrier to entry is much lower, too.
It does get easier.
|
|
|
|
|
Agree with r_hyde post and others that this is unit testing.
If you break each test into a separate, well-named method and add the right annotations in the right project type then it will be “testing framework ready” . It would eliminate your counter necessity and replace it with the method name.
Is it worth it? Not until you need to make another major enhancement on the subject class. Unless you want to do it as a learning exercise.
Before you start work on your next enhancement, clone your test class and refactor into a unit test.
Both tests should pass.
In the new unit test write the new tests for your enhancement. Run the tests and the new ones would fail until you implement the upgrades.
Depending on which version of IDE you have, you can use the unit tests to verify 100% code coverage in the subject. This is very powerful and has helped me in the past with a utility class similar to your range class.
I had written code for a range like [3,1] that treats it like [1,3] but did not have test cases for it. The coverage report caught my miss.
|
|
|
|
|
I'm curious: while working at the keyboard, do you listen to something? White noise, music, nature sounds? Dish.
|
|
|
|
|
At the moment, I'm enjoying the last of my precious silence: in under an hour, Herself will be home, and all I will hear is her oxygen machine, the TV on loud (as she's partly deaf), and herself screaming abuse at whatever show is on it.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Silence is golden for sure. I very often reset mental noise with forced silence.
|
|
|
|
|
|
Well, there is a single out already: 4'33" by John Cage[^]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: the TV on loud (as she's partly deaf)
That would annoy me to no end. I know it's not politically correct, and I understand it might be downright horrible for me to say this, but my position is that if you're the one with the affliction, then it's only respectful to try not to let that affect others. My solution in that scenario would be to wear headphones. I'm not just saying that when it applies to others. I'd be the first to do it if I was in that position.
But the world is built backwards. That's why I'm a single guy.
|
|
|
|
|
It's less annoying than her oxygen machine, which sounds like someone digging up the road outside with a Kango.
Fortunately she doesn't use it when we go to bed. Probably because she'd strangle herself with the piping when she "sausage rolled" herself with the entire duvet ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
Hawaiian Eye TV Show 1969-70's
|
|
|
|
|
Music, mostly electronic music of any genre.
With some old prog rock mixed in and some Qube Franco (Coeur de Pirate, Klo Pelgag, Pierre Lapointe...)
If it interests you, my top pick of last year.
Om Unit - Acid Dub Studies
Billie Eilish - Happier Than Ever .
The Black Dogs - Music For Photographers.
Coeur de Pirate - Perséides
For Those I Love - For Those I Love.
Loscil - Lux:Refractions
Plastikman - Narkosis/Spektre
Compilation Tresor - 30 years
A State Of Trance - 1000 (Celebration Mix)
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Thanks! I will check these out. My son loves electronic music and shares with me sometimes.
|
|
|
|
|
I normally don't listen to music while coding. If I do, I listen to classical music; Vivaldi being my favorite for some reason.
I also cannot talk on the phone and code at the same time.
|
|
|
|
|
The Four Seasons? Very nice.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
