Developers Who Test (and Don't)
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
Testing is pointless. By the time you're done writing the code to meet the requirements, the requirements change, and the changes remain a closely held secret until the day the code is scheduled to be delivered\submitted to be tested.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
And these are the people who write the code used by your bank, your car, your life support machine ... Frightening, isn't it?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
OriginalGriff wrote:
used by your bank, your car, your life support machine
User Acceptance Testing?
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
I assume you're referring to Unit Testing, not "I ran it and it works on my machine" Based on my experience the majority of software shops don't do testing, meaning it's not a required part of the development experience. I just started a new position.. no unit testing. Last position... HAHAHA - Testing?? Are you kidding??? Who's got time for that? Previous position.... Some unit tests in some teams Previous position.... What's a Unit Test??? Previous position.... I'm working 60+ hours/week... I don't have time for that... Previous position.... Looks like it's running... Send it to QA. . . . and so on. I think that there's a stigma associated with Testing that the primary purpose of a developer is to write code, and testing isn't code.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
Testing is pointless. By the time you're done writing the code to meet the requirements, the requirements change, and the changes remain a closely held secret until the day the code is scheduled to be delivered\submitted to be tested.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013John Simmons / outlaw programmer wrote:
By the time you're done writing the code to meet the requirements, the requirements change
Oh, silly you. You're talking about real software that exists in the real world. Testing is only for vaporware. That way we can('t) be sure we got it right and wrong. :laugh:
-
I assume you're referring to Unit Testing, not "I ran it and it works on my machine" Based on my experience the majority of software shops don't do testing, meaning it's not a required part of the development experience. I just started a new position.. no unit testing. Last position... HAHAHA - Testing?? Are you kidding??? Who's got time for that? Previous position.... Some unit tests in some teams Previous position.... What's a Unit Test??? Previous position.... I'm working 60+ hours/week... I don't have time for that... Previous position.... Looks like it's running... Send it to QA. . . . and so on. I think that there's a stigma associated with Testing that the primary purpose of a developer is to write code, and testing isn't code.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Kevin Marois wrote:
I think that there's a stigma associated with Testing that the primary purpose of a developer is to write code, and testing isn't code.
Yes, but the stigma of producing terrible code that literally crashes in production is far worse. The best kind of testing (and software development) occurs when a developer (no matter the level) literally thinks:
I _own_ this software and it represents me.
However, in corporate environments -- yes I work in one too -- this does not occur for many reasons: * dev is ignored anyways * dev has so many layers of management no one ever really talks to dev anyways * project is boring * project is doomed for other reasons anyways * there were no actual requirments created anyways, so anything could be accepted (screw it) * people in charge who are driving the project don't know anything about actual software dev anyways Too many more to list here.
-
I assume you're referring to Unit Testing, not "I ran it and it works on my machine" Based on my experience the majority of software shops don't do testing, meaning it's not a required part of the development experience. I just started a new position.. no unit testing. Last position... HAHAHA - Testing?? Are you kidding??? Who's got time for that? Previous position.... Some unit tests in some teams Previous position.... What's a Unit Test??? Previous position.... I'm working 60+ hours/week... I don't have time for that... Previous position.... Looks like it's running... Send it to QA. . . . and so on. I think that there's a stigma associated with Testing that the primary purpose of a developer is to write code, and testing isn't code.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
At my last position, we were responsible for making sure the code compiled, ran without exceptions, and updated the UI as expected. At that point, we handed it over to Q/A who had test cases to run the code against. We had to do this because most of the changes were UI changes, and you can't really automate them. All tests were run with a video capture so we could re-run the videos to see what the user did to make the code fault. It worked pretty well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
At my last position, we were responsible for making sure the code compiled, ran without exceptions, and updated the UI as expected. At that point, we handed it over to Q/A who had test cases to run the code against. We had to do this because most of the changes were UI changes, and you can't really automate them. All tests were run with a video capture so we could re-run the videos to see what the user did to make the code fault. It worked pretty well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Same with me on my last pos. And, the QA team was in India (:confused::confused: Don't ask me I didn't decide that) so after a check in we had to wait 24 hours for a testing cycle. I once knew a guy who sat next to me, and his idea of testing was to open a DOS Command Prompt, CD to the folder the app was in, and run the EXE, which then opened the app in Windows (It was a Windows Forms app). "It runs, so it's OK"
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
Same with me on my last pos. And, the QA team was in India (:confused::confused: Don't ask me I didn't decide that) so after a check in we had to wait 24 hours for a testing cycle. I once knew a guy who sat next to me, and his idea of testing was to open a DOS Command Prompt, CD to the folder the app was in, and run the EXE, which then opened the app in Windows (It was a Windows Forms app). "It runs, so it's OK"
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Kevin Marois wrote:
"It runs, so it's OK"
Which is only slightly more useful than, "It compiles. Ship it!"
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
Interesting. I have always eaten my own dogfood wherever practical and try to get everyone around me to do the same. Most larger shops have had decent QA but there is no point in passing untested code to QA in the hope that it'll scrape by - it won't. I really don't understand the notion of cobbling code to together and passing it up the chain without, at the very least, checking to make sure it does something along the lines of what was required. [EDIT} Perhaps it's because I come from an engineering background. You would not even consider letting a creation out of the shop without thorough testing. Perhaps that's what needs to be ingrained into the kiddies at uni.
-
Interesting. I have always eaten my own dogfood wherever practical and try to get everyone around me to do the same. Most larger shops have had decent QA but there is no point in passing untested code to QA in the hope that it'll scrape by - it won't. I really don't understand the notion of cobbling code to together and passing it up the chain without, at the very least, checking to make sure it does something along the lines of what was required. [EDIT} Perhaps it's because I come from an engineering background. You would not even consider letting a creation out of the shop without thorough testing. Perhaps that's what needs to be ingrained into the kiddies at uni.
R. Giskard Reventlov wrote:
I really don't understand the notion of cobbling code to together and passing it up the chain
I can't get inside that mentality either. It's quite terrible. I think it's either: 1. complete Ego-driven dev with a seasoning of laziness or 2. complete Lazy-driven dev with a seasoning of ego. :laugh:
-
R. Giskard Reventlov wrote:
I really don't understand the notion of cobbling code to together and passing it up the chain
I can't get inside that mentality either. It's quite terrible. I think it's either: 1. complete Ego-driven dev with a seasoning of laziness or 2. complete Lazy-driven dev with a seasoning of ego. :laugh:
:laugh:
-
Kevin Marois wrote:
I think that there's a stigma associated with Testing that the primary purpose of a developer is to write code, and testing isn't code.
Yes, but the stigma of producing terrible code that literally crashes in production is far worse. The best kind of testing (and software development) occurs when a developer (no matter the level) literally thinks:
I _own_ this software and it represents me.
However, in corporate environments -- yes I work in one too -- this does not occur for many reasons: * dev is ignored anyways * dev has so many layers of management no one ever really talks to dev anyways * project is boring * project is doomed for other reasons anyways * there were no actual requirments created anyways, so anything could be accepted (screw it) * people in charge who are driving the project don't know anything about actual software dev anyways Too many more to list here.
Ok drop the mask who are you of my colleagues? Knock the Imperial march on the desk so I can recognize you!
DURA LEX, SED LEX GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
Ok drop the mask who are you of my colleagues? Knock the Imperial march on the desk so I can recognize you!
DURA LEX, SED LEX GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
Sereiously, I've seen VERY few unit tests where I didn't think: There's no way this is EVER going to fail! And then I wonder: Why did you (not me, but the programmer who wrote it) waste your time writing the test (and running it over and over again)? :confused: And why do managers insist that you write tests for every tiny detail that can't possibly go wrong? I'm not against unit testing as such, but I think it's WAY overrated. To be fair, I HAVE seen tests that were actually were nice to have (and written one or two myself) - but mostly waste of time in my opinion! :doh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time -
And these are the people who write the code used by your bank, your car, your life support machine ... Frightening, isn't it?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
I happen to know persons who shall remain nameless who have built banking systems. Unnamed persons who had to sneak into the server center to run an upgrade at 2am to cover a small but fatal bug that was causing the bank's retail system to crash every day just after noon. I have no intention of naming the persons involved in that one or that I had to leave a half pint in the pub. :laugh:
veni bibi saltavi
-
John Simmons / outlaw programmer wrote:
By the time you're done writing the code to meet the requirements, the requirements change
Oh, silly you. You're talking about real software that exists in the real world. Testing is only for vaporware. That way we can('t) be sure we got it right and wrong. :laugh:
Those are probably Heisenbugs: they probably don't exist until some eejit tests for them. :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
Do you proofread your own prosa? Or do you review your own bookkeeping? Testing your own stuff is not such a great idea. You tend to build your misconceptions into the tests and sometimes you try to prove how good you are a little too hard. And these are just some unintentional reason why this can go all wrong.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Sereiously, I've seen VERY few unit tests where I didn't think: There's no way this is EVER going to fail! And then I wonder: Why did you (not me, but the programmer who wrote it) waste your time writing the test (and running it over and over again)? :confused: And why do managers insist that you write tests for every tiny detail that can't possibly go wrong? I'm not against unit testing as such, but I think it's WAY overrated. To be fair, I HAVE seen tests that were actually were nice to have (and written one or two myself) - but mostly waste of time in my opinion! :doh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the timeJohnny J. wrote:
but mostly waste of time in my opinion!
If your unit tests are a waste of time then you are doing it wrong. There's no point in writing unit tests unless they add to the quality of the code and give confidence that the software works as expected. The book you need to read is this one. [^]. It's the only book on the subject I recommend. You should quickly see improvements in your unit testing strategy.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
A quote from a former colleague: "Stop finding bugs, that's the clients (= user) job" And yes she was serious, and no that wasn't even my worst experience dealing with her.
Tom
