Test-driven voodoo magic
-
I recently started working at a large corporation that transitioned from a waterfall to an agile approach to software development about 2 years ago. As a part of the transition, developers who never fully understood test-driven development decided to start writing unit tests for their code to make it feel more agile. The results of their efforts are hundreds of unit tests with no clear purpose, goal, naming conventions, or coding standards. While trying to wrap my head around what possible benefit the unit tests offer, the best thing I can say about them is that they prove that random chunks of production code in private and public methods do the same thing as the unit tests which duplicate their logic whenever the constants specified in the unit tests match the values that haven't changed in the DEV database that they never mocked and the database connections and web services don't time out on them. I guess, in some abstract sense, running these unit tests could provide some benefit to the system, but we could improve the benefits by ignoring the unit tests and hiring a witch doctor to stand next to the source control server, sense the code's ethereal energy, and tell us if the code feels cursed or not. Know any witch doctors looking for employment?
-
I recently started working at a large corporation that transitioned from a waterfall to an agile approach to software development about 2 years ago. As a part of the transition, developers who never fully understood test-driven development decided to start writing unit tests for their code to make it feel more agile. The results of their efforts are hundreds of unit tests with no clear purpose, goal, naming conventions, or coding standards. While trying to wrap my head around what possible benefit the unit tests offer, the best thing I can say about them is that they prove that random chunks of production code in private and public methods do the same thing as the unit tests which duplicate their logic whenever the constants specified in the unit tests match the values that haven't changed in the DEV database that they never mocked and the database connections and web services don't time out on them. I guess, in some abstract sense, running these unit tests could provide some benefit to the system, but we could improve the benefits by ignoring the unit tests and hiring a witch doctor to stand next to the source control server, sense the code's ethereal energy, and tell us if the code feels cursed or not. Know any witch doctors looking for employment?
Perhaps you could set the server on a nice, comfortable couch and have a psychologist discuss the "daddy issues" with the code, due to inept "parent" programmers..? Same thing.
-
I recently started working at a large corporation that transitioned from a waterfall to an agile approach to software development about 2 years ago. As a part of the transition, developers who never fully understood test-driven development decided to start writing unit tests for their code to make it feel more agile. The results of their efforts are hundreds of unit tests with no clear purpose, goal, naming conventions, or coding standards. While trying to wrap my head around what possible benefit the unit tests offer, the best thing I can say about them is that they prove that random chunks of production code in private and public methods do the same thing as the unit tests which duplicate their logic whenever the constants specified in the unit tests match the values that haven't changed in the DEV database that they never mocked and the database connections and web services don't time out on them. I guess, in some abstract sense, running these unit tests could provide some benefit to the system, but we could improve the benefits by ignoring the unit tests and hiring a witch doctor to stand next to the source control server, sense the code's ethereal energy, and tell us if the code feels cursed or not. Know any witch doctors looking for employment?
jesarg wrote:
but we could improve the benefits by ignoring the unit tests and hiring a witch doctor to stand next to the source control server, sense the code's ethereal energy, and tell us if the code feels cursed or not.
: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) -
I recently started working at a large corporation that transitioned from a waterfall to an agile approach to software development about 2 years ago. As a part of the transition, developers who never fully understood test-driven development decided to start writing unit tests for their code to make it feel more agile. The results of their efforts are hundreds of unit tests with no clear purpose, goal, naming conventions, or coding standards. While trying to wrap my head around what possible benefit the unit tests offer, the best thing I can say about them is that they prove that random chunks of production code in private and public methods do the same thing as the unit tests which duplicate their logic whenever the constants specified in the unit tests match the values that haven't changed in the DEV database that they never mocked and the database connections and web services don't time out on them. I guess, in some abstract sense, running these unit tests could provide some benefit to the system, but we could improve the benefits by ignoring the unit tests and hiring a witch doctor to stand next to the source control server, sense the code's ethereal energy, and tell us if the code feels cursed or not. Know any witch doctors looking for employment?
jesarg wrote:
stand next to the source control server, sense the code's ethereal energy, and tell us if the code feels cursed or not.
I didn't know it was a recognised technique - I've been doing my testing that way for years... :-D
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
I recently started working at a large corporation that transitioned from a waterfall to an agile approach to software development about 2 years ago. As a part of the transition, developers who never fully understood test-driven development decided to start writing unit tests for their code to make it feel more agile. The results of their efforts are hundreds of unit tests with no clear purpose, goal, naming conventions, or coding standards. While trying to wrap my head around what possible benefit the unit tests offer, the best thing I can say about them is that they prove that random chunks of production code in private and public methods do the same thing as the unit tests which duplicate their logic whenever the constants specified in the unit tests match the values that haven't changed in the DEV database that they never mocked and the database connections and web services don't time out on them. I guess, in some abstract sense, running these unit tests could provide some benefit to the system, but we could improve the benefits by ignoring the unit tests and hiring a witch doctor to stand next to the source control server, sense the code's ethereal energy, and tell us if the code feels cursed or not. Know any witch doctors looking for employment?
jesarg wrote:
hiring a witch doctor to stand next to the source control server
Hmm. I administer a number of SourceSafe data bases. Maybe sacrificing small animals is what I've been missing...
Software Zen:
delete this; -
I recently started working at a large corporation that transitioned from a waterfall to an agile approach to software development about 2 years ago. As a part of the transition, developers who never fully understood test-driven development decided to start writing unit tests for their code to make it feel more agile. The results of their efforts are hundreds of unit tests with no clear purpose, goal, naming conventions, or coding standards. While trying to wrap my head around what possible benefit the unit tests offer, the best thing I can say about them is that they prove that random chunks of production code in private and public methods do the same thing as the unit tests which duplicate their logic whenever the constants specified in the unit tests match the values that haven't changed in the DEV database that they never mocked and the database connections and web services don't time out on them. I guess, in some abstract sense, running these unit tests could provide some benefit to the system, but we could improve the benefits by ignoring the unit tests and hiring a witch doctor to stand next to the source control server, sense the code's ethereal energy, and tell us if the code feels cursed or not. Know any witch doctors looking for employment?
I only know a lazy cargo cult Java team. They turn everything into a hollow useless ritual that's not worth the work you put into it. They also wanted me to write unit tests. The problem was that they were far too agile to provide any specifications about what might be correct and what is not correct. To be precise, they were not able to come up with any specifications at all. So I was creative and tested everything that might possibly go wrong that came to my mind. The result was that practically all the tests failed, once I checked them in. Oh horror! The build ritual failed! And how did they 'fix' it? No, not by looking at the tests and sorting out where the tests might be too strict or where they might be pointing out some issues. They simply commented out all the code in the tests and checked them in again. Now the build ritual does not fail anymore and the unit test ritual also has been sucessfully completed. Bravo! Now you can go back to sleep and hold up your build reports with 100% sucessful unit tests when somebody asks.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
I only know a lazy cargo cult Java team. They turn everything into a hollow useless ritual that's not worth the work you put into it. They also wanted me to write unit tests. The problem was that they were far too agile to provide any specifications about what might be correct and what is not correct. To be precise, they were not able to come up with any specifications at all. So I was creative and tested everything that might possibly go wrong that came to my mind. The result was that practically all the tests failed, once I checked them in. Oh horror! The build ritual failed! And how did they 'fix' it? No, not by looking at the tests and sorting out where the tests might be too strict or where they might be pointing out some issues. They simply commented out all the code in the tests and checked them in again. Now the build ritual does not fail anymore and the unit test ritual also has been sucessfully completed. Bravo! Now you can go back to sleep and hold up your build reports with 100% sucessful unit tests when somebody asks.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
they were not able to come up with any specifications at all.
Looks quite familiar to me. Someone in our company decided then that we desperately need to get a test tool...
-
CDP1802 wrote:
they were not able to come up with any specifications at all.
Looks quite familiar to me. Someone in our company decided then that we desperately need to get a test tool...
Keep the managers busy, distract them, so they leave you alone.. lol I just test, as a user would. I'm a programmer & designer & db admin & test tool. :laugh: *throws a bone to manager to keep him busy with something else* FETCH!
-
I only know a lazy cargo cult Java team. They turn everything into a hollow useless ritual that's not worth the work you put into it. They also wanted me to write unit tests. The problem was that they were far too agile to provide any specifications about what might be correct and what is not correct. To be precise, they were not able to come up with any specifications at all. So I was creative and tested everything that might possibly go wrong that came to my mind. The result was that practically all the tests failed, once I checked them in. Oh horror! The build ritual failed! And how did they 'fix' it? No, not by looking at the tests and sorting out where the tests might be too strict or where they might be pointing out some issues. They simply commented out all the code in the tests and checked them in again. Now the build ritual does not fail anymore and the unit test ritual also has been sucessfully completed. Bravo! Now you can go back to sleep and hold up your build reports with 100% sucessful unit tests when somebody asks.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
Now the build ritual does not fail anymore and the unit test ritual also has been sucessfully completed. Bravo! Now you can go back to sleep and hold up your build reports with 100% sucessful unit tests when somebody asks.
Wouldn't that be NaN% successful? Or did they only comment out the code INSIDE the tests, not the tests themselves?
-
CDP1802 wrote:
Now the build ritual does not fail anymore and the unit test ritual also has been sucessfully completed. Bravo! Now you can go back to sleep and hold up your build reports with 100% sucessful unit tests when somebody asks.
Wouldn't that be NaN% successful? Or did they only comment out the code INSIDE the tests, not the tests themselves?
Exactly, they commented out everything inside the tests that could potentially fail, mostly the assertions. They did leave the parts which call methods, so that the tests still 'cover' much of the code.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
I only know a lazy cargo cult Java team. They turn everything into a hollow useless ritual that's not worth the work you put into it. They also wanted me to write unit tests. The problem was that they were far too agile to provide any specifications about what might be correct and what is not correct. To be precise, they were not able to come up with any specifications at all. So I was creative and tested everything that might possibly go wrong that came to my mind. The result was that practically all the tests failed, once I checked them in. Oh horror! The build ritual failed! And how did they 'fix' it? No, not by looking at the tests and sorting out where the tests might be too strict or where they might be pointing out some issues. They simply commented out all the code in the tests and checked them in again. Now the build ritual does not fail anymore and the unit test ritual also has been sucessfully completed. Bravo! Now you can go back to sleep and hold up your build reports with 100% sucessful unit tests when somebody asks.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
cargo cult
The expression I was gonna use! :thumbsup: There seem to be no lack of cargo culting around agile sadly.
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood 'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
-
Exactly, they commented out everything inside the tests that could potentially fail, mostly the assertions. They did leave the parts which call methods, so that the tests still 'cover' much of the code.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
I recently started working at a large corporation that transitioned from a waterfall to an agile approach to software development about 2 years ago. As a part of the transition, developers who never fully understood test-driven development decided to start writing unit tests for their code to make it feel more agile. The results of their efforts are hundreds of unit tests with no clear purpose, goal, naming conventions, or coding standards. While trying to wrap my head around what possible benefit the unit tests offer, the best thing I can say about them is that they prove that random chunks of production code in private and public methods do the same thing as the unit tests which duplicate their logic whenever the constants specified in the unit tests match the values that haven't changed in the DEV database that they never mocked and the database connections and web services don't time out on them. I guess, in some abstract sense, running these unit tests could provide some benefit to the system, but we could improve the benefits by ignoring the unit tests and hiring a witch doctor to stand next to the source control server, sense the code's ethereal energy, and tell us if the code feels cursed or not. Know any witch doctors looking for employment?
that is the default testing technique used by millions of programmers. unless you have good dedicated programmers who really care about their code this unit testing BS will not yield any fruit...and the catch is if you have good programmers then very rarely they would need unit tests as they will write it right the first time. I deal with such programmers everyday they add 5 items to a list then check if the list has 5 items as if there was some leak in CLR.
