Test your code until your brains ooze from your eye sockets
-
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.
-
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(); }
}
