Test your code until your brains ooze from your eye sockets
-
I agree, but as coder trying to test, try as I may there is always a "conflict of interest". As much as I hate to admit it, the coder in me is trying to prove that it is solid, while the tester is trying to prove that it is broken. I can happily test until my visual apparatus exudes neural material - but is someone else tests my code, they will always find things I missed because my mind was to odeeply into the code - likewise I am quite good at breaking someone else's "well-tested" code. Trouble is, management usually won't give you the luxury of a dedicated tester (or test team).
Just achieve 110% code coverage in your testing :). 100% coverage is that every branch is tested. 110% is when you test that every condition that can get you into every branch, is also tested. You'll find all those buggy error handling paths. You'll find all those buggy conditions. You'll even find a bunch of (error handling) code elsewhere in the project that's buggy. Still not perfect through, for starters, you'll miss all the design and requirements interpretation errors. If there's multiple paths to exercise the same code, you'll usually miss some of those too. Like you said, there's just no substitute for having someone else test your code.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
I agree: testing your own code will never produce half as many bugs as testing another's. The reason is simple: you only test cases that you can think of. But if you can think of them, you've probably covered them in your code. It's only when some comes around with test cases that you didn't think of that the truly nasty bugs turn up.
We get better at things by concentrating on getting better at them. When you start thinking up tests cases in the first year of doing it.. you'll be dreadfully bad at it.. but after 20+ years, you'll understand your own flaws and look for all the edge cases. I've seem too many programmers say they can't do it, when its all a matter of concentrated practice. We get better by doing. Your own bugs teach you your blind spots.. This is exactly why its important to support your own code.. and get that critical feedback to make you a better tester of it.
-
I always hate "pilot" projects. You get a subset of the data to develop around. Then they schedule the full dataset as though there won't be any changes necessary. Every. Time. There will be data that does not fit. Once we had a pilot project to convert addresses from one system to another. Management wanted consistency in department titles. After doing the pilot and coming up with a conversion table, the full run was as though we had done nothing. It would have been better to run the whole 1.2 million addresses than just the 50,000 they had given us. In the end, we found 150 different ways the data entry clerks had come up with to indicate "Human Resources". And that is just for one department. I just finished another conversion that I was given a pilot set of data for. Again, the full set had conditions not encountered in the subset. Hard to test around those situations.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
and then test it some more. There is absolutely no excuse for not testing your code...EVER! I was in a hurry about a month ago and did not test some Perl script. I just spent the last 4 hours paying the price. Gotta love it. :shakes head:
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011)Personally, I love tracking down esoteric bugs, digging through source code and following the trail of bytes, determining which component fired the fatal shot and from what angle by reconstructing the bit spray pattern, performing genetic analysis on the traces of data persisting in memory, checking alibi's ('I was working on another piece of code', 'pretty sure that's a bug in a 3rd party component', 'I've been framed!' etc) and establishing motive ('gotta get it done', 'whOOOps!', 'I'm pretty sure that's a bug in a 3rd party component', 'That method was always causing me problems', 'I was just taking orders'). It's like I'm in Code Scene Investigation: Las Bugas... At least that's what I tell myself at 4am, when I'm delirious, pulling my hair out and looking for a reason to live... :)
-
Personally, I love tracking down esoteric bugs, digging through source code and following the trail of bytes, determining which component fired the fatal shot and from what angle by reconstructing the bit spray pattern, performing genetic analysis on the traces of data persisting in memory, checking alibi's ('I was working on another piece of code', 'pretty sure that's a bug in a 3rd party component', 'I've been framed!' etc) and establishing motive ('gotta get it done', 'whOOOps!', 'I'm pretty sure that's a bug in a 3rd party component', 'That method was always causing me problems', 'I was just taking orders'). It's like I'm in Code Scene Investigation: Las Bugas... At least that's what I tell myself at 4am, when I'm delirious, pulling my hair out and looking for a reason to live... :)
Nice read. :thumbsup:
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) -
and then test it some more. There is absolutely no excuse for not testing your code...EVER! I was in a hurry about a month ago and did not test some Perl script. I just spent the last 4 hours paying the price. Gotta love it. :shakes head:
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011)I agree with you totally, however I am seeing a disturbing trend in the other direction. Let's test. Manual testing takes too long. Let's automate the tests. There is a Service Center application called Orchestrator.(SCO) It has something called a Runbook, which is basically a graphical tool to schedule tasks and coordinate the information generated in the tasks. SCO allows you to do this with any code, but in order to do it, you need to define the IP (integration pack), register and deploy it. OK, but now we need to test the IPs and we need automated tests to do it. I set up some Runbooks to monitor their behavior working against SCOM. (Operation Manager) Get a feel for how they run. Load the automated tests on the server I had just successfully run some books, they simply will not run. I ask for help. "Oh, it runs just fine." "How!?" "Oh, I just loaded SCOM on your SCO server." So, how come I am the only one with the clarion bell ringing in my head that we are NOT testing the IPs like this supposedly automated test does?
-
That depends on which direction your company is going. In the company I'm at, good coders are leaving because of the bad ones. The bad ones aren't budging.
Our case is worse... We never could get good programmers, because we're a small company in a small backwater place (which I still proudly call my home! :)). So the programming paradigm the company has always had was "everybody should be able to read it"-code... That means that endless nested loops and if then else's are easier to read than a SOLID principle or Design Pattern (Interface was a curse word...). When I started my programming career there I mostly learned what NOT to do. After I raised some hell with management and actually called my boss' code a "card house that will fall when things get bigger" they really started hating me. When after some weeks it turned out I was right about the card house thing did they start to take me serious and we are now coding more solid code than we ever did :) Though I was able to restore some balance to the code, we are still left with tons of legacy code and databases from the dark side...
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Pffft. If it compiles, ship it.
-
I always hate "pilot" projects. You get a subset of the data to develop around. Then they schedule the full dataset as though there won't be any changes necessary. Every. Time. There will be data that does not fit. Once we had a pilot project to convert addresses from one system to another. Management wanted consistency in department titles. After doing the pilot and coming up with a conversion table, the full run was as though we had done nothing. It would have been better to run the whole 1.2 million addresses than just the 50,000 they had given us. In the end, we found 150 different ways the data entry clerks had come up with to indicate "Human Resources". And that is just for one department. I just finished another conversion that I was given a pilot set of data for. Again, the full set had conditions not encountered in the subset. Hard to test around those situations.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
BrainiacV wrote:
I just finished another conversion that I was given a pilot set of data for. Again, the full set had conditions not encountered in the subset.
By 1992 I was consistently using the phrase "It isn't tested until it's tested against real data."
-
BrainiacV wrote:
I just finished another conversion that I was given a pilot set of data for. Again, the full set had conditions not encountered in the subset.
By 1992 I was consistently using the phrase "It isn't tested until it's tested against real data."
Quote:
"It isn't tested until it's tested against real data."
I like it! :-D I shall add that to my set of stock phrases, like "If I can't reproduce it, I can't fix it."
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
I agree: testing your own code will never produce half as many bugs as testing another's. The reason is simple: you only test cases that you can think of. But if you can think of them, you've probably covered them in your code. It's only when some comes around with test cases that you didn't think of that the truly nasty bugs turn up.
Too true. Many years (decades!) ago I was "programming manager" at a software vendor. I bet my team that I could break (find a bug in) any piece of code they said was ready to go live, and would buy them a beer if I couldn't. It was many weeks (and zero beers) later that someone finally twigged that if they wanted a free beer, they had to get one of their mates to test their code - if they only tested it themselves they were going to die of thirst. Yes, of course we should have had a formal test team, peer reviews etc etc but this was (a) over 20 years ago and (b) the more senior management didn't see the need for it; that was partly because I (re-)tested most stuff before go-live and picked up the worst of the howlers.
-
and then test it some more. There is absolutely no excuse for not testing your code...EVER! I was in a hurry about a month ago and did not test some Perl script. I just spent the last 4 hours paying the price. Gotta love it. :shakes head:
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011)The One and True Answer: "It Works On My Machine!"
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
