The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
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.
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.
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.
I've always built application without performing unit tests. They all worked and looked good. The client didn't need to know about that as they don't know what unit tests are. I performed my own tests and tried to catch as much workflows as possible, and it has always worked for me.
I was afraid to tell anyone this but:
"I don't do unit tests!!!!!!!!!"
So what you're saying is that it's worth spending the company's time and money for a few weeks to develop parsing algorithms to determine whether objects embedded in an Excel document correspond to the given API call and/or data instead of using human visual acuity for an hour in printing and verifying 20 odd reports?
You are technically correct, it could be done, however we are not in the business of doing what could be done. We are in the business of doing what is required by our clients so that they improve efficiency and make money. Asinine unit testing, especially wrt UI and reporting where functional testing is vastly better at catching subtlties, is an obsessive scourge brought about by software engineers who found a new hammer and saw everything as nails.
Yes, but irrelevant. As much as you're trying to portray me as an incompetent boob, you're at risk of seeming to be an expensive liability. Unit testing has it's place, typically away from human interactive aspects of the application where, in my experience, most exceptions occur as a consequence of multiple interactions in unusual sequences. These are seldom caught by unit tests which are by design more atomic in their testing.
Well, maybe it's not a competency issue. You can do it. But you don't want to.
Is it because you don't find it valuable?
Also, even if this software isn't a great candidate to be unit tested, there would still be value in having a suite of automated functional tests to validate it's functionality. This would help you if you need to test your product with different versions of Office, including future ones. It's also easier to transfer your code to another programmer, even an intern. You can trust that they probably won't screw things up too bad as long as your tests are run with whatever changes they make (within reason. tests can't catch everything.) If you were to quit the company, it would certainly be easier for someone else to understand and take over your work if there were a great set of automated tests. Is the product moving to a maintenance phase where others have to support it for years to come? Think of those maintenance programmers, who may be outsourced.
However, even without functional testing, there's logic in your code that is independent of the user interface which could benefit from being unit tested.
It's a lot of work, without direct benefit to that sales guy that you showed the report to, and harder to justify your time doing. A lot of great reasons not to do the right thing, which is why so many people don't do it.
In the end, this is a management issue. If the managers don't require programmers to deliver on automated tests, then they won't get it, and they're the ones that will ultimately suffer. If they do require it, the programmer really won't have much of a choice, unless he doesn't want to get a paycheck.
You're still thinking solely along engineering lines. This is irrelevant to the situation I described. What MAY happen in the future is a probability, it is a calculated risk.
Also you're weighing time spent developing now as equal to time spent developing in the future. This is wrong. Time spent now is more expensive then time spent in the future. Time spent now solving or mitigating theoretical future upgrades is much much much more expensive then time spent in the future fixing it.
This is perhaps because you're seeing the software project as the be all and end all. It's not, the product helps others perform their tasks more effectively thereby improving their productivity and reducing costs. Cost savings net overtime and can be allocated into more productive tasks netting an even higher ROI. Delaying a product with the aim of producing perfect testing reduces the potential ROI by constraining the time the productivity boost would otherwise have to work. This ultimately will cost more than fixing issues in the future. In the end it's up to the project sponsers to weigh these competing factors and decide the most reasonable path. Creating unit tests, though feasible, for a reporting engine was simply not cost effective.
Unit testing seems to have become the new Gospel of testing over the last 5 or 6 years, but like all IT holy crusades it was led solely by an Engineering mindset whilst ignoring that ever annoying bogeyman we like to call the real world.
Time spent now is a lot cheaper than time spent in the future.
This is not about designing for features that don't yet exist. This is about developing a complete solution for the software you're delivering now. Maintainability is built-in, not added on, so are pretty much every other non-functional requirement.
Not if it delays deployment, and not if deployment is delayed to mitigate what *might* happen.
Seesh, please read the replies.
Time spent building a decent architecture may reduce future costs if you have a good idea of what will be required. If not it won't since you're designing against what might be there, and so far as I know there isn't a recognized profession of Clairvoyent Software Engineer. Similarly spending significant extra time developing unit tests of no immediate value to the client costs more than future fixes if it forces delays in deployment. Sales Persons had no reliable way of dynamically generating reports in the field. That means lost sales. That means lost revenue. That means lost profit.
It's nice that you want to reduce the work load on future developers, but ultimately it's *probable* future work thus not real work or therein a real cost. It's considered a fractional cost as it's a risk and not an absolute which again makes work now more expensive.
I feel supremely confident that I'm a good source to verify that CBA decision was a good one since I was actually there and helped make it. Apparently you were there too and disagreed? I'm sorry I don't remember you. All code dealing directly with the automation objects were abstracted to well documented classes. This was deemed sufficient to mitigate future risk. If you can recall what your viewpoint was at the meeting, please remind me ...