It's OK Not to Write Unit Tests
-
-
-
I once was like you. Testing is nice and such, but mocking this and mocking that is a pain. That is, until I found the perfect product for me. Why should I ever have to mock a file system or database access, If there's a packaged product that does this for me? Once you recognize that it is silly of thousands of developers to individually mock tiny fragments, you realize there must be a complete, mroe holistic approach. MockOS[^] - all my unit tests run on it. :cool:
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server -
Nemanja, correct me if I’m wrong, but I think this entire “unit testing” madness originates from Java. Regarding my experience lot of the Java dedicated programmers are also enthusiastic in writing unit tests.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
Nemanja, correct me if I’m wrong, but I think this entire “unit testing” madness originates from Java. Regarding my experience lot of the Java dedicated programmers are also enthusiastic in writing unit tests.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
Deyan Georgiev wrote:
I think this entire “unit testing” madness originates from Java
IMHO, it is from Smalltalk - switched to Java folks. The same crowd that invented "Extreme Programming", "Design Patterns", etc. Anyway, I am happy to see that even Java programmers are comming to their senses[^]
-
Deyan Georgiev wrote:
I think this entire “unit testing” madness originates from Java
IMHO, it is from Smalltalk - switched to Java folks. The same crowd that invented "Extreme Programming", "Design Patterns", etc. Anyway, I am happy to see that even Java programmers are comming to their senses[^]
Nemanja Trifunovic wrote:
IMHO, it is from Smalltalk - switched to Java folks. The same crowd that invented "Extreme Programming", "Design Patterns", etc.
We need to uninvent them.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
Nemanja, correct me if I’m wrong, but I think this entire “unit testing” madness originates from Java. Regarding my experience lot of the Java dedicated programmers are also enthusiastic in writing unit tests.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
I once spent 3 months writing a reporting API in C# that spat out Excel docs sucking data from a localized data cube. Now the sales guys and gals could wow potential clients and it was generally well received. 'Twas a thing of surprising beauty considering it featured the words "Excel" and "reporting" in it. Then a Java guy plodded over and wanted to see the Unit Tests. I had none. He pointed out it was policy, and demanded to know how I could qualify a generated report. I jokingly suggested that I build an Excel document parser and run it against different templates based on desired output. He was not amused. Then I ran the app, set it for one year for one product variety and ran the report. I handed the printout to an Argentinean sales rep who happened to be in the office to see a demo. He said it looked good. Unit test complete.
10110011001111101010101000001000001101001010001010100000100000101000001000111100010110001011001011
-
Wow, I thought unit testing was all about focusing on the functionality of a quite logical independent unit, "not (a) test (that) cannot talk to a database, communicate across the network, touch the filesystem, run concurrently with another test, or require extensive setup. If they are any dependencies, they are mocked away". Dogmatic approaches are pretty useless for me. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Wow, I thought unit testing was all about focusing on the functionality of a quite logical independent unit, "not (a) test (that) cannot talk to a database, communicate across the network, touch the filesystem, run concurrently with another test, or require extensive setup. If they are any dependencies, they are mocked away". Dogmatic approaches are pretty useless for me. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Right. If I write a method that connects to a database and I want to unit test it, it had better connect to an actual database.
-
Right. If I write a method that connects to a database and I want to unit test it, it had better connect to an actual database.
That's not "against the law" when writing tests. What you just described is an integration test.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
From the article: Unit testing is no substitute for adversarial testing. A man after my own heart. Too many companies think that testers should be chums with engineering. That's dumb. Testers should have an adversarial relationship with engineering; their job isn't to prove a product works, but that it doesn't. Another way to put it is that testers should think engineers are arrogant assholes and set out to prove it. Engineering should be attempting prove otherwise. That said, I do think "unit" testing has it's place. When I write libraries and classes, I want to make sure they work the way I designed them to work. Writing them in a slightly more organized way helps me to debug them as well. (One of the beefs I do have with many testing suites is that they are awful in helping you debug.) However, I never for a moment believe that I'm doing anything but testing low level functionality and that it's any substitute for system/integration testing. (I'd even say that if my company were big enough and we had a separate testing department, they wouldn't use any of my tests. They'd write their own!) (I should point out that I use "unit" testing quite loosely here. When testing classes, I test them as a class. I just rewrote a Trie class; my test put stuff in and looked it up--I tested only the public interfaces, which tests the protected/private interfaces. But what about those private interfaces that aren't used by the public interfaces? There aren't any.)
-
Nemanja Trifunovic wrote:
A very nice article that describes my pain points with unit testing as well[^].
Actually, I found the article to be overly abstract, convoluted, and ultimately pointless. It certainly didn't pass my "mental unit test." It was the comments to the article that kept my interest, and frankly were much better than the article itself (and a lot more entertaining!) Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
That's not "against the law" when writing tests. What you just described is an integration test.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
Judah Himango wrote:
is an integration test
I don't quite see it that way; in my opinion, connecting to A database isn't the same as connecting to THE database.
-
I once was like you. Testing is nice and such, but mocking this and mocking that is a pain. That is, until I found the perfect product for me. Why should I ever have to mock a file system or database access, If there's a packaged product that does this for me? Once you recognize that it is silly of thousands of developers to individually mock tiny fragments, you realize there must be a complete, mroe holistic approach. MockOS[^] - all my unit tests run on it. :cool:
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server -
Unit tests like so much methodology these days are simply ways to commoditize software development. Nothing more, nothing less and like cows to slaughter most developers eat up these kinds of methodologies like candy all the while ignoring the fact that these were designed primarily to make us replaceable worthless cogs in a big machine of corporate development. Unit tests are on most levels counterproductive and worthless to any decent software developer who can recognize bad code before or while they are writing it and nip it in the bud. They're great for accounting and managerial types though so .... yay for them! :) Software developers used to be gods in their domain, now they're just easily replaced cogs in a giant machine of mediocrity and have no one to blame but themselves when their work can be easily outsourced or indeed they themselves can be easily replaced with someone cheaper and less experienced.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
One more nice article about unit testing[^]
Giorgi Dalakishvili #region signature My Articles Asynchronous Registry Notification Using Strongly-typed WMI Classes in .NET [^] My blog #endregion
-
I think the main problem with unit testing is the assumption that anyone can right a "complete" set of tests. If anyone was capable of doing that their code probably wouldn't need testing in the first place because they'd have covered all scenarios in the code itself as well. But the thing I love about unit testing is the fact that you can test stuff in minutes that would literally take hours to test properly otherwise. For example you've got a web app in which you need to login, navigate down a couple of pages then fill in a form then click GO! The old approach to testing starts when you click GO! With unit testing you can simulate the login process and the form data and have a whole range of tests without needing to use a browser or make up another set of form data. In practice I've found it means you test stuff much more thouroughly even if that doesn't mean "completely" and also that you can test those bits of code that may never have been touched by navigating through some front end or other in order to do your testing.
-
Unit tests like so much methodology these days are simply ways to commoditize software development. Nothing more, nothing less and like cows to slaughter most developers eat up these kinds of methodologies like candy all the while ignoring the fact that these were designed primarily to make us replaceable worthless cogs in a big machine of corporate development. Unit tests are on most levels counterproductive and worthless to any decent software developer who can recognize bad code before or while they are writing it and nip it in the bud. They're great for accounting and managerial types though so .... yay for them! :) Software developers used to be gods in their domain, now they're just easily replaced cogs in a giant machine of mediocrity and have no one to blame but themselves when their work can be easily outsourced or indeed they themselves can be easily replaced with someone cheaper and less experienced.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
Judah Himango wrote:
is an integration test
I don't quite see it that way; in my opinion, connecting to A database isn't the same as connecting to THE database.
So it's a mock database
-
From the article: Unit testing is no substitute for adversarial testing. A man after my own heart. Too many companies think that testers should be chums with engineering. That's dumb. Testers should have an adversarial relationship with engineering; their job isn't to prove a product works, but that it doesn't. Another way to put it is that testers should think engineers are arrogant assholes and set out to prove it. Engineering should be attempting prove otherwise. That said, I do think "unit" testing has it's place. When I write libraries and classes, I want to make sure they work the way I designed them to work. Writing them in a slightly more organized way helps me to debug them as well. (One of the beefs I do have with many testing suites is that they are awful in helping you debug.) However, I never for a moment believe that I'm doing anything but testing low level functionality and that it's any substitute for system/integration testing. (I'd even say that if my company were big enough and we had a separate testing department, they wouldn't use any of my tests. They'd write their own!) (I should point out that I use "unit" testing quite loosely here. When testing classes, I test them as a class. I just rewrote a Trie class; my test put stuff in and looked it up--I tested only the public interfaces, which tests the protected/private interfaces. But what about those private interfaces that aren't used by the public interfaces? There aren't any.)