开云体育

That was JB's proposition. A good way to seed an active discussion is to throw in a red herring. :-) If we wanted to be precise, I'd correct it to say "One can learn design skill _while_ practicing

The major point of software design is to make the code easy to understand, and therefore easy to work on. I learned enough about software design fro

But TDD doesn't teach you about coupling and cohesion, it doesn't teach you about 'clean code' (whatever you determine that to mean), it doesn't even teach you about removal of duplication - that's

I would say that there are multiple levels of design, including architecture, systems design, security design, and so on. TDD isn’t intended to help with those. It helps you get to clean code, based

The best design does not exist in some timeless, isolated vacuum. A design is only best with respect to the actual requirements for the software. The actual requirements are always a moving target

The original proposition, partly, as stated is: I feel this falls into the trap of not being clear about what we mean when we say TDD. If one defines TDD as a process. Red, Green, Refactor. First

Hey, Charlie and Gregory, Thanks for your message. Where did I get that from... This is a good question! In the bubble of engineers I follow, I sometimes get the impression that people believe that

These three. I remember about the time I was getting into TDD, sitting in a design session with some hot-shots from an MIT-founded company and the deer-in-the-headlights freeze because of the cost of

"IMHO, TDD doesn't magically guide you to good design.". Very true. However, it very concretely enables fast feedback loops. The fastest available anywhere. The closest rival is probably web UI

Mauricio, I believe like you "TDD doesn't magically guide you to good design", because it's not magic, it's focus. Do you agree that TDD in itself can be seen as a frame that ensure you to think about

For me, learning TDD the hard way (by doing it a lot, badly, with little guidance beyond the books and dev blogs available in the early oughts) led to a massive improvement in my software design

Hi Mauricio, You make an interesting point, saying that the JUnit 5 extensibility model "was clearly created by someone who profoundly understands object-oriented design principles and how to build

Hi, JB! Thanks for starting such an interesting thread. I'm a strong believer in a slight variation of what you said. If you want to get the best out of TDD, you need to deeply know about software

Refactoring to simplify code leads to cleaner designs. If nothing else, you should get a better feel for what makes a clean design. On the other hand, if by “design” you’re thinking mainly

I agree that the naming can be confusing because often the same name means different things to different people. I don't get too hung up on the naming of types of tests (though I love Gpaw's

To me the best is freedom from the fear of making changes to the codebase late in time. From another perspective I also like the rails that TDD provides to my development: I have a repeatable way to

Kevin, My experience supports that. I learned to be a much better OO designer by practicing TDD. It gave me the freedom to correct the design flaws I'd made, and see how much better coding worked

- freedom from having to hold the details of the assumptions of dependent code in you head, the tests will let you know if you violate them (to the extent you express those assumptions in tests) -

Freedom from frequent, long debugging sessions

Freedom to refactor, knowing you can check your work after each variable rename to know if you've made a mistake.