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: :~
Sometimes it's better that the original developer doesn't write the (automated) tests. Sometimes all that means is that the developers misconception of the requirements gets written twice. OTOH, a test script that runs through all the expected interactions is useful, and yes, the basic test data for those interactions. That said, most place I've worked don't have dedicated testers - just user acceptance testers.
-
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: :~
Sure, programmers should do some unit and module testing. But too often, programmers test their software when used the way it is supposed to be used. It is not like the "five year old test": Place a five year old by the keyboard and tell him "You just do what you want to do, and you'll have another ice cream cone every time you make the program crash". Real testing must be done by "misbehaved" testers. People who are paid by the number of bugs they find, not by the number of code lines they write. 30 years ago, before software testing was an established discipline, we used student summer interns: If they stayed with us for more than half a year, they learned the programmer's way of thinking, using the software the intended way, and the number of bugs detected gradually. Every summer we got a new group of students, unfamiliar with the software, and the detected bugs count rose sharply. Nowadays, we have a separate testing team - full time, but then: They are educated in the discipline of testing. Their profession is to identify corner cases, defining stress testing, managing bugs databases (programmer solution: add a comment in the code: "To do: Fix this bug when time allows" :-)), and rating the severeness of the bugs, making sure that the all the serious bugs are really fixed before the product is released. Besides: Their job is to bark at the programmers when bugs are found that should never have been made at all. Programmers don't like to be barked at. So they do proper unit and module tests just as much to quiet down the testers as to satisfy the customers :-) I think the t-shirt I am wearing today is somehow related to my own program/bug-writing experience - it says "Experience - the ability to recognize a mistake when you repeat it". That certainly describes my experience when my code goes to the testers.
-
I fit into option one: The ego will not allow me to deliver crappy code - the QA (users) are anally retentive, pedants who delight in sending back a bug report. Laziness - I loathe writing the same code twice.
Never underestimate the power of human stupidity RAH
-
I must be so freakin' old. It would never occur to me to give someone something attributable to me without making sure it works. I've wasted so much time. If there's a problem then someone would probably tell me if it were really important. So much time wasted.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"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
W∴ Balboos wrote:
It would never occur to me to give someone something attributable to me without making sure it works.
That's exactly how I feel about it. It was literally like listening to a crazy person when he said he hadn't even shot one element of data through the thing. Crazy! And, you're not old, you have a fine attention to The Craft of Software Development. (Also, I'm old too.) :laugh:
-
If for nothing else, I find unit tests the quickest way to debug new features and check they actually work. Far quicker than manually clicking through UI controls until you get to your new feature / bug fix. Although I have worked with devs who pass on to QA without even running through the code themselves . .
Absolutely! Great comment. Griping about unit tests and/or just not doing them is akin to griping about Source Control. If you don't understand how much value Source Control brings as a developer and you only see it as overhead, then you probably don't really understand a lot about real dev. Source Control is annoying at times, but it saves so much work. Same thing for unit tests.
-
Sometimes it's better that the original developer doesn't write the (automated) tests. Sometimes all that means is that the developers misconception of the requirements gets written twice. OTOH, a test script that runs through all the expected interactions is useful, and yes, the basic test data for those interactions. That said, most place I've worked don't have dedicated testers - just user acceptance testers.
AndrewDavie wrote:
just user acceptance testers.
That's a good way to look at this and it sparked a thought in me. User Acceptance testers can decide whether the software meets the user requirements and bascially fulfills the outward contract. So the testing could determine that the software is 100% correct. However, without unit tests the design underneath could be so terrible that as soon as the customer wants to add an "easy change" the design may be so brittle that everything falls apart. So unit tests and other tests can/may indicate where the design is broken or bad and those kinds of tests would never be found by acceptance testers. Good comment. Made me think.
-
Sure, programmers should do some unit and module testing. But too often, programmers test their software when used the way it is supposed to be used. It is not like the "five year old test": Place a five year old by the keyboard and tell him "You just do what you want to do, and you'll have another ice cream cone every time you make the program crash". Real testing must be done by "misbehaved" testers. People who are paid by the number of bugs they find, not by the number of code lines they write. 30 years ago, before software testing was an established discipline, we used student summer interns: If they stayed with us for more than half a year, they learned the programmer's way of thinking, using the software the intended way, and the number of bugs detected gradually. Every summer we got a new group of students, unfamiliar with the software, and the detected bugs count rose sharply. Nowadays, we have a separate testing team - full time, but then: They are educated in the discipline of testing. Their profession is to identify corner cases, defining stress testing, managing bugs databases (programmer solution: add a comment in the code: "To do: Fix this bug when time allows" :-)), and rating the severeness of the bugs, making sure that the all the serious bugs are really fixed before the product is released. Besides: Their job is to bark at the programmers when bugs are found that should never have been made at all. Programmers don't like to be barked at. So they do proper unit and module tests just as much to quiet down the testers as to satisfy the customers :-) I think the t-shirt I am wearing today is somehow related to my own program/bug-writing experience - it says "Experience - the ability to recognize a mistake when you repeat it". That certainly describes my experience when my code goes to the testers.
-
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 also find that if you want to make testable code, stay as "functional" in your programming as much as possible. Anecdote: I recently had to rework a monolithic module. The final result was 4 independent modules (separation of concerns) that were pure functional (inputs, outputs, no side effects) which generated almost the same information, but it was a lot easier to test/debug/capture intermediate results/replay/prove/etc. The functional/separated modules actually were a lot cleaner and faster (less iterations) since one data structure in the old monolithic was split into separate,focused structures in the new modules. After the refactor was complete, then the new requirements were added with clearly observable/diff-able results in outputs of the affected modules.
-
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.
-
Absolutely! Great comment. Griping about unit tests and/or just not doing them is akin to griping about Source Control. If you don't understand how much value Source Control brings as a developer and you only see it as overhead, then you probably don't really understand a lot about real dev. Source Control is annoying at times, but it saves so much work. Same thing for unit tests.
I've only been in the trade for 4 years so perhaps that is before my time. I can't even imagine working without source control. That includes personal projects, but particularly for collaboration. What is the alternative to source control when working as a team? Emailing code around? Store on network drive? Word of mouth? Passenger pigeon? Reminds me of the time I received a printed XML in the post..
-
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, 2013I assume that you are joking. If there were any truth at all to what you are saying, then your software architecture certainly should be revised. Sure requirements change, but not into a completely different problem. The basic task is still the same, and thre great majority of the modules stay unchanged. Those that are modified, are usuall functionally extended, or, for user/protocol interface modules, mostly reorganized. If every requirement change invalidates all tests for all modules and subsystems, then I would be scared to use your code for anytning at all. Even if you are joking (which I certainly hope): Too often you see arguments very close to the one you make, but said in dead earnest. "This is just a temporary solution". "The testing procedures are not yet updated to account for the changes" etc. We should be very sensitive to that kind of arguments, and immediately set down our foot.
-
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: :~
Need a review when you're done. In 35 years, I've not yet worked in a shop that actually had deliberate testing. Sure, as the developer, you do (at least it's what I hold myself to) have a resp. to see that the code does basically what it's supposed to do. We only joke about "it compiled and linked, should be good".
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
urlonz wrote:
What is this "requirements" you speak of.
:laugh: It's funny...as long as it is someone else trying to hit a unknown target. Sales: Users want a thing. Dev: Uh, can you describe it to me? Let's meet and gather some requirements. Sales: Can't you just build it? Are you stupid or something? You aren't really a dev are you? I asked Bill-Bob in Tech support who knows Python and he said he can build it for me in 2 days. Dev: Billy-Bob is a genius!! Go for it. :laugh:
-
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: :~
Me: can you provide instructions on how to test your code? Current Co-worker: I can't think in that kind of mind set. Me: :confused: co-worker also refuses to answer most emails - they don't want to be pinned to a paper trail. It really sucks on so many levels.
-
I also find that if you want to make testable code, stay as "functional" in your programming as much as possible. Anecdote: I recently had to rework a monolithic module. The final result was 4 independent modules (separation of concerns) that were pure functional (inputs, outputs, no side effects) which generated almost the same information, but it was a lot easier to test/debug/capture intermediate results/replay/prove/etc. The functional/separated modules actually were a lot cleaner and faster (less iterations) since one data structure in the old monolithic was split into separate,focused structures in the new modules. After the refactor was complete, then the new requirements were added with clearly observable/diff-able results in outputs of the affected modules.
Excellent commentary. My primary customer makes a lot of different industrial machines. One of the primary engineering tasks is testability - how do we know this thing actually works? Keeps the electrical and mechanical engineers busy. No reason why the same principles could not be applied to the software.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
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: :~
-
Me: can you provide instructions on how to test your code? Current Co-worker: I can't think in that kind of mind set. Me: :confused: co-worker also refuses to answer most emails - they don't want to be pinned to a paper trail. It really sucks on so many levels.
-
The next two words out of Dev's Boss' mouth should be: 1) "You're" and 2) should start with a "f" and end with an "ed".
-
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: :~
Gives you a whole new perspective on driverless car software huh? Speed: 60 kph Terrain: mountain road on a bridge over a chasm Altitude: 2000 meters above sea level Forward Sensors: 5 workers on the road 10 meters ahead Reverse Sensors: tractor trailer approaching at 65 kph 20 meters back Plow into the workers (5 killed)? Veer off the bridge? (1 killed: passenger)? Things that make you go hmmmmmm.
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright "I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
-
urlonz wrote:
What is this "requirements" you speak of.
:laugh: It's funny...as long as it is someone else trying to hit a unknown target. Sales: Users want a thing. Dev: Uh, can you describe it to me? Let's meet and gather some requirements. Sales: Can't you just build it? Are you stupid or something? You aren't really a dev are you? I asked Bill-Bob in Tech support who knows Python and he said he can build it for me in 2 days. Dev: Billy-Bob is a genius!! Go for it. :laugh:
How many times have I had this conversation. Real-life conversation between me and a member of sales as we sat down to lunch one day: Sales: Hey, how is the Project X thing going along? Dev: What's Project X? Sales: You know, Project X. We've been selling it over the last month. Dev: Never heard of it. Sales: Geez, man. We have a client coming onboard next week. Dev: I guess you should explain to me just what you've been selling. Sales: I don't have time for that, but you need to get on that right away.