341–350 of 450 posts
If testing gets in the way is because the design doesn't emphasize testing.
Then, if you have high coupling, you have high complexity and a stronger reason to test.
Seems a little arrogant to say most developers don't know how to refactor or do it poorly. Maybe it's true. I really can't say one way or the other because what I see is most devs believe they don't have time to refactor.
Try asking them:
"if you had the time to do it 'well', what would you have done differently?"
(By the way, the same works for testing: "if you had the time to write all the tests you want, how would you test this code?")
You might be surprised.
Earlier quoted context omitted.
They thought "refactoring" was a made-up word that programmers used to cover up dicking around and wasting time. From a non-programmer's perspective, all they see is the programmer spending several hours with the end result being that nothing has visibly changed. The thing is, many refactoring efforts make code worse, not better. Refuctoring is something I've observed many times over, by people who consider themselve…
Did you intend to say "Refuctoring"? It could be a typo or it could be clever wordplay. And it leads to two drastically different interpretations of what you're saying :)
Earlier quoted context omitted.
No. TDD failed for engineering reasons in addition to economic ones. The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software. This is true in bridge building as much as it is in anything else. Until you fully know the domain of what you are building, you cannot possibly know all of the things you need to test for. To that end, if TDD were focused aroun…
It's worth noting that Kent Beck ("Father of TDD") himself said that TDD doesn't always make sense. For him, the important thing has always been having a tight feedback loop for determining if he was still on the right track. For instance, when he was working on an unstructured log parser, there was no way TDD would work because the logging stream didn't have a pre-defined structure. Instead, he developed a process w…
Earlier quoted context omitted.
I was quite comfortable with refactoring for a very long time before I started doing tests, and I think that colors my approach to the problem space. I write code until it misbehaves the first time, and then I start writing tests, comfortable in the knowledge that in another half hour this code will be unit testable and look better than what everyone else is turning in, and that I'll spend 20 minutes at the end clean…
What language?
TDD failed? What no it didn't? When was the last time you depended on the use of an untested library for a major project?
Earlier quoted context omitted.
Transcription can lead to the same conditional in two blocks of similar code instead of the two intended. It can lead to fencepost errors due to changing or inverting an inequality. And in some languages it can lead to code that looks up data that doesn't exist (misspell a property name outside the happy path). The big problem is that you're chewing up short term memory slots that used to hold the next thing you plan…
> Transcription can lead to the same conditional in two blocks of similar code instead of the two intended. It can lead to fencepost errors due to changing or inverting an inequality. And in some languages it can lead to code that looks up data that doesn't exist (misspell a property name outside the happy path). Funnily enough, all of those are also problems with copy-and-paste. But they're much more likely to occur…
Earlier quoted context omitted.
What language?
C#. Resharper is a really, really good tool, and I also use NCrunch (a continuous test runner) when I do TDD.
It's possibly the single tool[0] I'll miss from the .Net world when I program in Java.
(For anyone who might be wondering why not Resharper that is because that functionality is provided out-of-the-box with all major Java IDEs. On .Net however, Resharper seems to be almost a must-have for many.)
[0]: I'll be missing Asp.Net MVC, parts of Entity Framework and parts of the C# language too.
"developers are quick to pick up the workflow and can create working code and tests during classes/exercises/katas – and then failing in the real world."
The anathema of TDD is that people equate having well defined test cases to a solid product that brings the solution that the user wants. I have seen far more software projects boasting of >85% of code coversge for tests, but still failing spectacularly.
TDD failed because it was assumed as the magic wand that aligns the end product with what's on spec and the process that it would cover, but the reality of human behavior being merely coded to test cases is far out from reality.