TDD for dummies !
-
I often see TDD is dead, no longer exists blah blah. Well this might help for anyone who is confused want to shape up him/her self.
If you write code, write tests The pupil asked the master programmer : “When can I stop writing tests?” The master answered : “When you stop writing code.” The pupil asked : “When do I stop writing code?” The master answered : “When you become a manager.” The pupil trembled and asked : “When do I become a manager?” The master answered : “When you stop writing tests.” The pupil rushed to write some tests.He left skid marks. If the code deserves to be written,it deserves to have tests.
.... The Way Of Testivus[^]
Wonde Tadesse
Codefucious, he say "Man who code and not test, He a farkin' eejit"
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
I often see TDD is dead, no longer exists blah blah. Well this might help for anyone who is confused want to shape up him/her self.
If you write code, write tests The pupil asked the master programmer : “When can I stop writing tests?” The master answered : “When you stop writing code.” The pupil asked : “When do I stop writing code?” The master answered : “When you become a manager.” The pupil trembled and asked : “When do I become a manager?” The master answered : “When you stop writing tests.” The pupil rushed to write some tests.He left skid marks. If the code deserves to be written,it deserves to have tests.
.... The Way Of Testivus[^]
Wonde Tadesse
Nice, but writing tests is one thing and having a test-based *design* something very different.
-
Nice, but writing tests is one thing and having a test-based *design* something very different.
-
I often see TDD is dead, no longer exists blah blah. Well this might help for anyone who is confused want to shape up him/her self.
If you write code, write tests The pupil asked the master programmer : “When can I stop writing tests?” The master answered : “When you stop writing code.” The pupil asked : “When do I stop writing code?” The master answered : “When you become a manager.” The pupil trembled and asked : “When do I become a manager?” The master answered : “When you stop writing tests.” The pupil rushed to write some tests.He left skid marks. If the code deserves to be written,it deserves to have tests.
.... The Way Of Testivus[^]
Wonde Tadesse
-
I often see TDD is dead, no longer exists blah blah. Well this might help for anyone who is confused want to shape up him/her self.
If you write code, write tests The pupil asked the master programmer : “When can I stop writing tests?” The master answered : “When you stop writing code.” The pupil asked : “When do I stop writing code?” The master answered : “When you become a manager.” The pupil trembled and asked : “When do I become a manager?” The master answered : “When you stop writing tests.” The pupil rushed to write some tests.He left skid marks. If the code deserves to be written,it deserves to have tests.
.... The Way Of Testivus[^]
Wonde Tadesse
LOL!
What do you get when you cross a joke with a rhetorical question?
-
Nice, but writing tests is one thing and having a test-based *design* something very different.
Agreed. But it starts by knowing the basic which is Testing.
Wonde Tadesse
-
Just 2 things: 1st "I often see TDD is dead!" it's a good header if you want to get some pageviews 2nd TDD is not just writing tests...
AlexCode wrote:
"I often see TDD is dead!"
May be/ May be not. Who knows the outcome!
AlexCode wrote:
TDD is not just writing tests...
Agree. Starts with "T" testing though. If he/she continues his/her dumbness, will follow another round for TDD for Dummmies 102, 202 even 400 and 500 once ! :)
Wonde Tadesse
-
I often see TDD is dead, no longer exists blah blah. Well this might help for anyone who is confused want to shape up him/her self.
If you write code, write tests The pupil asked the master programmer : “When can I stop writing tests?” The master answered : “When you stop writing code.” The pupil asked : “When do I stop writing code?” The master answered : “When you become a manager.” The pupil trembled and asked : “When do I become a manager?” The master answered : “When you stop writing tests.” The pupil rushed to write some tests.He left skid marks. If the code deserves to be written,it deserves to have tests.
.... The Way Of Testivus[^]
Wonde Tadesse
TDD as a religion should die. In my previous contract the team (before I joined) followed their own (misguided) interpretation of DDD and TDD. They had an awful lot of passing unit and integration tests (pats on back and a slice of cake for everyone, hoorah! :java:), but the project didn't work properly from the users perspective, it continually missed all it's deadlines and after spending over £1 million on it, the team and the project have been canned (I'd got out before then, it was obvious from the start where the project was heading - I'd raised issues with management, but it all fell on deaf ears). If you're developing a product, it's the product that matters at the end of the day, not the tests. TDD is a nice to have, but it's far from essential.
-
TDD as a religion should die. In my previous contract the team (before I joined) followed their own (misguided) interpretation of DDD and TDD. They had an awful lot of passing unit and integration tests (pats on back and a slice of cake for everyone, hoorah! :java:), but the project didn't work properly from the users perspective, it continually missed all it's deadlines and after spending over £1 million on it, the team and the project have been canned (I'd got out before then, it was obvious from the start where the project was heading - I'd raised issues with management, but it all fell on deaf ears). If you're developing a product, it's the product that matters at the end of the day, not the tests. TDD is a nice to have, but it's far from essential.
I keep seeing a JavaTDD role advertised, I was wondering TDD was a tool box, but from this it appear to a half- bottomed approach to testing...(think I will stay clear...) :)
-
I keep seeing a JavaTDD role advertised, I was wondering TDD was a tool box, but from this it appear to a half- bottomed approach to testing...(think I will stay clear...) :)
Don't get me wrong, I'm not anti-TDD but it's a means to an end, it's not the end in itself. Too many developers get obsessed with having every possible angle covered by unit tests, in many cases the size of the unit tests become significantly larger than what they're testing. The worst thing is when you see an awful architecture with classes with 32 dependencies - or more - being injected (yes, I have seen this, hard as it is to believe :wtf:) into the constructor, then you see the huge amount of objects being mocked in the unit tests!?!? TDD in itself is a good thing, but in practice I've rarely seen it used in a good way. It's not the fault of TDD, much in the same way as it's not a guns fault someone gets shot. For every team where TDD works my experience is that there are many more teams where it doesn't because of the poor team culture and/or way it's being implemented.
-
TDD as a religion should die. In my previous contract the team (before I joined) followed their own (misguided) interpretation of DDD and TDD. They had an awful lot of passing unit and integration tests (pats on back and a slice of cake for everyone, hoorah! :java:), but the project didn't work properly from the users perspective, it continually missed all it's deadlines and after spending over £1 million on it, the team and the project have been canned (I'd got out before then, it was obvious from the start where the project was heading - I'd raised issues with management, but it all fell on deaf ears). If you're developing a product, it's the product that matters at the end of the day, not the tests. TDD is a nice to have, but it's far from essential.
-
Don't get me wrong, I'm not anti-TDD but it's a means to an end, it's not the end in itself. Too many developers get obsessed with having every possible angle covered by unit tests, in many cases the size of the unit tests become significantly larger than what they're testing. The worst thing is when you see an awful architecture with classes with 32 dependencies - or more - being injected (yes, I have seen this, hard as it is to believe :wtf:) into the constructor, then you see the huge amount of objects being mocked in the unit tests!?!? TDD in itself is a good thing, but in practice I've rarely seen it used in a good way. It's not the fault of TDD, much in the same way as it's not a guns fault someone gets shot. For every team where TDD works my experience is that there are many more teams where it doesn't because of the poor team culture and/or way it's being implemented.
Even worse, farkloads of dependency injection, levels of indirection and hopelessly complex and abstruse APIs to facilitate "proper" design, and then.... No tests. Orrrr.... Out of date tests that are never run, and one hopeless soul in a corner who's not really good enough to be a developer but was hired because the budget isn't there for a dedicated test team so we need a muppet to hand-test the entire sorry ball of sh.... Yeeeah. TDD has improved code quality? No it damn well has not. If anything it's become yet anohter excuse for lazy, lackadaisical people to call themselves "architects". Do it right, or not at all. And a good team of coders can minimize the need for test coverage by using decent, intelligent coding practices in the day-to-day.
I too dabbled in pacifism once.
-
Even worse, farkloads of dependency injection, levels of indirection and hopelessly complex and abstruse APIs to facilitate "proper" design, and then.... No tests. Orrrr.... Out of date tests that are never run, and one hopeless soul in a corner who's not really good enough to be a developer but was hired because the budget isn't there for a dedicated test team so we need a muppet to hand-test the entire sorry ball of sh.... Yeeeah. TDD has improved code quality? No it damn well has not. If anything it's become yet anohter excuse for lazy, lackadaisical people to call themselves "architects". Do it right, or not at all. And a good team of coders can minimize the need for test coverage by using decent, intelligent coding practices in the day-to-day.
I too dabbled in pacifism once.
On the project I mentioned, the first warning signs to the team should have been that there were 149 projects in the solution (C#, MVC4) yet all it actually did was show a login form (and even that didn't work properly!) :doh: And when you mention anything you get the usual "you don't understand TDD/DDD", "that's an anti-pattern", "what you're suggesting isn't Agile", etc. (i.e. ways to try and prevent any discussion of the real problems).
-
If a Test Fails in the night, and no ones there to see it: Does it make an error?!
Not until I log into my computer the next morning and see the cruisecontrol.net icon in my tray has turned red. :laugh:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Don't get me wrong, I'm not anti-TDD but it's a means to an end, it's not the end in itself. Too many developers get obsessed with having every possible angle covered by unit tests, in many cases the size of the unit tests become significantly larger than what they're testing. The worst thing is when you see an awful architecture with classes with 32 dependencies - or more - being injected (yes, I have seen this, hard as it is to believe :wtf:) into the constructor, then you see the huge amount of objects being mocked in the unit tests!?!? TDD in itself is a good thing, but in practice I've rarely seen it used in a good way. It's not the fault of TDD, much in the same way as it's not a guns fault someone gets shot. For every team where TDD works my experience is that there are many more teams where it doesn't because of the poor team culture and/or way it's being implemented.
:thumbsup:
-
On the project I mentioned, the first warning signs to the team should have been that there were 149 projects in the solution (C#, MVC4) yet all it actually did was show a login form (and even that didn't work properly!) :doh: And when you mention anything you get the usual "you don't understand TDD/DDD", "that's an anti-pattern", "what you're suggesting isn't Agile", etc. (i.e. ways to try and prevent any discussion of the real problems).
Brent Jenkins wrote:
there were 149 projects in the solution (C#, MVC4) yet all it actually did was show a login form
My jaw quite literally dropped open when I read this. I know I'm guilty of gold-plating my code, but the worst I've ever gone on a single application is 9 projects. :doh:
-
On the project I mentioned, the first warning signs to the team should have been that there were 149 projects in the solution (C#, MVC4) yet all it actually did was show a login form (and even that didn't work properly!) :doh: And when you mention anything you get the usual "you don't understand TDD/DDD", "that's an anti-pattern", "what you're suggesting isn't Agile", etc. (i.e. ways to try and prevent any discussion of the real problems).
Brent Jenkins wrote:
the first warning signs to the team should have been that there were 149 projects in the solution
Seems like that would have been more like the 100th warning sign unless all of those projects just showed up all at once in the middle of the night.
Brent Jenkins wrote:
and prevent any discussion of the real problems
Process, any process, that doesn't allow change in response to actual work is guaranteed to fail.
-
Brent Jenkins wrote:
there were 149 projects in the solution (C#, MVC4) yet all it actually did was show a login form
My jaw quite literally dropped open when I read this. I know I'm guilty of gold-plating my code, but the worst I've ever gone on a single application is 9 projects. :doh:
Mine too - when I first opened the solution there were already over 130 projects there. I'd previously seen a solution with 50 projects in another contract - that was too many as well, but they had accumulated over a few years and it did actually (mostly) do what it was supposed to. Most solutions I come across seem to have between 10 and 15 projects including test projects. I'd say once 20 project is reached, red warning lights should be flashing. Not that it's necessarily wrong, but at that point it's probably worth considering if a different approach may be more appropriate.
-
Brent Jenkins wrote:
the first warning signs to the team should have been that there were 149 projects in the solution
Seems like that would have been more like the 100th warning sign unless all of those projects just showed up all at once in the middle of the night.
Brent Jenkins wrote:
and prevent any discussion of the real problems
Process, any process, that doesn't allow change in response to actual work is guaranteed to fail.
Agreed, as I mentioned in another post, most solutions I come across tend to be between 10 and 15 projects including test projects. Anything higher than 20 is time to review and reconsider the design. The most ridiculous thing was that Visual Studio struggled (unsurprisingly) to keep running. So brilliant suggestions flowed forth - such as doubling the amount of RAM on each PC, fitting SSD drives, changing the methodology from Agile to Waterfall (why that would help I have no idea?), and finally removing required functionality from the requirements documents because of the difficulties getting anything done because the architecture was extremely brittle and fragile. Anything and everything except dumping the solution and building it properly. Ah well, at least I can laugh about it all now with only a small dose of medication :laugh:
