|
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. 
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
|
|
|
|
|
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 – ∞)
|
|
|
|
|
Nice, but writing tests is one thing and having a test-based *design* something very different.
|
|
|
|
|
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
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
|
|
|
|
|
LOL!
What do you get when you cross a joke with a rhetorical question?
|
|
|
|
|
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 | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif) ), 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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
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  ) 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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
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!) 
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).
modified 31-Aug-21 21:01pm.
|
|
|
|
|
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.
|
|
|
|
|
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
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
modified 31-Aug-21 21:01pm.
|
|
|
|
|
|
lol
did we work on the same project?
|
|
|
|
|
Possibly, or perhaps it's an indication how pervasive problems are in interpretations of TDD across the board
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Brent Jenkins wrote : TDD as a religion should die
I'm not a follower of TDD as religion.
When I come to you point. Well I don't blame on TDD. I blame the team who wrongly practicing it. Off course, if anyone who abuse the methodology will eventually fail.Same is true for OOP, Design Patterns so on so forth.
Brent Jenkins wrote : it's the product that matters at the end of the day, not the tests
Agree, it just a matter of making the best robust product. TDD will contribute it's share and most importantly it's alive.
Wonde Tadesse
|
|
|
|
|
Wonde Tadesse wrote: I'm not a follower of TDD as religion.
Me neither, but an awful lot of development teams are - you can find yourself being hunted down by the Coding Inquisition[^] (and all their cunning instruments of torture) by not covering one obscure line of code with a unit test.
Wonde Tadesse wrote: Well I don't blame on TDD. I blame the team who wrongly practicing it.
That's exactly my point! While there a few organisations who have got it right, the vast majority are abusing various methodologies - they just don't realise it. Every place has it's own implementation/interpretation made up to suit themselves. Surely they can't all be right?
The "religion" angle is basically a defensive mechanism to prevent anyone questioning why things are being done in a certain (often illogical) way - a bit like the old days of shouting "heretic" at anyone who was deemed a threat.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
O proud left foot, that ventures quick within
Then soon upon a backward journey lithe.
Again, once more the gesture, then begin;
Command sinistral pedestal to writhe.
Commence thou then the fervid Hokey-Poke.
A mad gyration, hips in wanton swirl.
To spin! A wilde release from heaven's yoke.
Blessed dervish! Surely canst go, girl.
The hoke, the poke--banish now thy doubt
Verily, I say, 'tis what it is all about.
Author: Jonathan Mayberry
Ok so I'm bored, taking a break from EdX Linux class. I've done 12 chapter since last night.
Have you ever just looked at someone and knew the wheel was turning but the hamster was dead?
Trying to understand the behavior of some people is like trying to smell the color 9.
|
|
|
|
|
Thou'rt most awesome, Sir Mike.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
