Test your code until your brains ooze from your eye sockets
-
A colleague recently 'fixed' something. I later found out I couldn't even open the friggin form after he had fixed it. It was such a small fix he didn't think it would've been necessary to test it... Worst part is that I didn't check his fix and put it live at the customer! Now who's the jackass? My non-testing, over-confident colleague or me, the one responsible :) Of course I'm not innocent myself, but I always at least test what I just fixed (that some other part of our software breaks because of the 'fix' is just details ;p ).
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Naerling wrote:
Now who's the jackass?
umm... Your process. Always blame the process :-\
A year spent in artificial intelligence is enough to make one believe in God
-
Naerling wrote:
Now who's the jackass?
umm... Your process. Always blame the process :-\
A year spent in artificial intelligence is enough to make one believe in God
Actually we always blame people that don't work at the company anymore ;p
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Actually we always blame people that don't work at the company anymore ;p
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Always a good technique - and often true, as those who've left are the ones who couldn't code well enough!
-- What's a signature?
-
Yeah!:thumbsup: Real artists ship, not test.
Henry Minute Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is. Cogito ergo thumb - Sucking my thumb helps me to think.
What was that cliché again about "starving artists"?...
Software Zen:
delete this; -
Always a good technique - and often true, as those who've left are the ones who couldn't code well enough!
-- What's a signature?
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.
-
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, 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).
-
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) -
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.
-
I'm trying to get management to make some changes to stop the bad developers from doing stuff worthy of the hall of shame, while at the same time looking for something better. We'll see which happens first...
-
Pffft. If it compiles, ship it.
Compile? Huh? Wuss!!! :P I just RDP into the server, write a few lines and save. Then I go for a smoke. If the phone rings, something went wrong.
-
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 problem with that mantra is that there is no software without bugs, so you'll always find some! For practical reasons you should therefore set a reasonable limit to your testing. Hint: 'no more bugs found' is not a reasonable limit. ;)
-
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).
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.
-
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)So true. I'm reminded of this comic: http://blogs.msdn.com/b/seliot/archive/2011/04/25/i-don-t-always-test-my-code-but-when-i-do-i-do-it-in-production.aspx[^]
-
The problem with that mantra is that there is no software without bugs, so you'll always find some! For practical reasons you should therefore set a reasonable limit to your testing. Hint: 'no more bugs found' is not a reasonable limit. ;)
Stefan_Lang wrote:
The problem with that mantra is that there is no software without bugs, so you'll always find some!
For practical reasons you should therefore set a reasonable limit to your testing. Hint: 'no more bugs found' is not a reasonable limit.You will always find bugs, I agree with this. However, I never tested the code in question, at all. That is the reason for the Mantra. I catch so many bugs and problems just by testing my own code before you give it to the users to test. To not test your code, thoroughly on a basis of principal, indicates to me that you might not be a good coder. (not you in particular :))
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) -
Pffft. If it compiles, ship it.
Damn straight! Back when I was doing S/370 Assembler programming, I'd point to the line at the end of the listing...
NO ERRORS FOUND
:laugh:
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)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.
-
I'm trying to get management to make some changes to stop the bad developers from doing stuff worthy of the hall of shame, while at the same time looking for something better. We'll see which happens first...
Once management is entrenched in supporting stupidity, all bottom up/grass roots efforts at making things better are destined to fail. The only way you can fix a situation like that is to be a top level manager and incent the right behavior and fire those that don't follow. This is a lesson I've learned the hard way.
-
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.
