Course in Software Engineering

[woohoo]

You could just turn around and admin that TDD doesn't mean what you thought it did.

It's not a difficult concept, I get it - I've read the books even tried the various approaches. If writing unit tests helps you design/comment/change your code then good for you. But I think all that could be more easily achieved and I disagree with you about how popular TDD is based on my experience.

Your examples of nails, hammers and cabinets are just plain daft and embarrassing.

[GlenW]

To continue the decorating analogy:

Without TDD: "That's not the colour I wanted."

With TDD: "I know this is the colour you wanted because it matches the swatch I showed you before I started."

Real World: "That's not the swatch you showed me."

[browntractor]

I've just written an app, I went through it with the other devs, here is the pattern, MVC->service layer (sometimes)->repository layer->dapper. The MVC screen's followed the same pattern, index, edit, new, same naming convention for view models etc. Used DI, so showed them where the binding was done. So, the code followed a predictable pattern and you could easily understand it. I can't see any reason to add unit tests to this project.
.

If these layers merely delegate to the lower layer, I agree with you. Normally, in a nontrivial app you would have business logic in the service layer - that should be unit tested. Then some turnip (like me) can come along and change the code without having to understand all of it- because the tests will tell me that I have not broken anything. That saves a lot of time, and allows me to make confident encapsulated changes. I really should not have to look at lots of code to change one small bit.

But, TDD is a 10-15 year old paradigm where the developer starts out by writing a bunch of tests, which when all passing , flag the system as functionally complete. That's not what you are describing - you are talking about standard unit testing practices. That's not TDD, though it is used in TDD. I've only met a handful of people who actually do TDD. Most developers are onboard with the benefit of unit testing these days- maintainability.

[SpontaneousOrder]

It's not a difficult concept, I get it - I've read the books even tried the various approaches. If writing unit tests helps you design/comment/change your code then good for you. But I think all that could be more easily achieved and I disagree with you about how popular TDD is based on my experience.

Your examples of nails, hammers and cabinets are just plain daft and embarrassing.

Didn't say it was popular. I said it's the standard by which almost all of the thought leaders in the different dev communities will judge your engineering practises. This is a new phenomenon.

Most people don't do TDD, which is why those thought leaders are banging on about it so much, to the point that a great many of them describe anything less as negligent.

[SpontaneousOrder]

To continue the decorating analogy:

Without TDD: "That's not the colour I wanted."

With TDD: "I know this is the colour you wanted because it matches the swatch I showed you before I started."

Real World: "That's not the swatch you showed me."

No. You're implying that in the real world customers change their minds?

[woohoo]

If these layers merely delegate to the lower layer, I agree with you. Normally, in a nontrivial app you would have business logic in the service layer - that should be unit tested. Then some turnip (like me) can come along and change the code without having to understand all of it- because the tests will tell me that I have not broken anything. That saves a lot of time, and allows me to make confident encapsulated changes. I really should not have to look at lots of code to change one small bit.

But, TDD is a 10-15 year old paradigm where the developer starts out by writing a bunch of tests, which when all passing , flag the system as functionally complete. That's not what you are describing - you are talking about standard unit testing practices. That's not TDD, though it is used in TDD. I've only met a handful of people who actually do TDD. Most developers are onboard with the benefit of unit testing these days- maintainability.

So the benefit in this example is that because TDD is used you can see how the class or classes are used within the unit tests and you can change, if the tests are up to date and all pass then you are good to go.

So for me if the application is designed correctly you will have classes that pretty much do one thing or use other classes to chain actions together. The class and methods will describe what they do and it should be pretty obvious from how they are used by their caller classes what they do. If you change something you should test it. Even in a TDD environment I would expect changes to be tested.

Regarding most developers being onboard, I'm not sure this is true. I've read the books, I've written the tests then the code etc and I'm not on-board. The developers I work with are not on-board, the developers at various clients are not on-board.

[SpontaneousOrder]

If these layers merely delegate to the lower layer, I agree with you. Normally, in a nontrivial app you would have business logic in the service layer - that should be unit tested. Then some turnip (like me) can come along and change the code without having to understand all of it- because the tests will tell me that I have not broken anything. That saves a lot of time, and allows me to make confident encapsulated changes. I really should not have to look at lots of code to change one small bit.

But, TDD is a 10-15 year old paradigm where the developer starts out by writing a bunch of tests, which when all passing , flag the system as functionally complete. That's not what you are describing - you are talking about standard unit testing practices. That's not TDD, though it is used in TDD. I've only met a handful of people who actually do TDD. Most developers are onboard with the benefit of unit testing these days- maintainability.

So the benefit in this example is that because TDD is used you can see how the class or classes are used within the unit tests and you can change, if the tests are up to date and all pass then you are good to go.

So for me if the application is designed correctly you will have classes that pretty much do one thing or use other classes to chain actions together. The class and methods will describe what they do and it should be pretty obvious from how they are used by their caller classes what they do. If you change something you should test it. Even in a TDD environment I would expect changes to be tested.

Regarding most developers being onboard, I'm not sure this is true. I've read the books, I've written the tests then the code etc and I'm not on-board. The developers I work with are not on-board, the developers at various clients are not on-board.

You missed the bit from browntractors post which I've highlighted.

Thi sis why none of your post makes sense.

[woohoo]

You missed the bit from browntractors post which I've highlighted.

Thi sis why none of your post makes sense.

Ok gotcha - it's hard getting into discussion with you religious folk. I guess you are also still smarting that I called your examples daft and embarrassing?

[browntractor]

So the benefit in this example is that because TDD is used you can see how the class or classes are used within the unit tests and you can change, if the tests are up to date and all pass then you are good to go.

So for me if the application is designed correctly you will have classes that pretty much do one thing or use other classes to chain actions together. The class and methods will describe what they do and it should be pretty obvious from how they are used by their caller classes what they do. If you change something you should test it. Even in a TDD environment I would expect changes to be tested.

Regarding most developers being onboard, I'm not sure this is true. I've read the books, I've written the tests then the code etc and I'm not on-board. The developers I work with are not on-board, the developers at various clients are not on-board.

The benefit of unit tests is that the next developer can come along, change some code - quickly run the unit tests and be confident nothing broke. Your kind of point and click validation of a change is much more error prone. You can then have environmental dependencies break you. We've all seen a dev say "but it worked on my box".

And to your point on classes with one purpose not needing testing. You imply a class with multipurposes would need testing. The unit of encapsulation is the only thing that differs. In your world I would be testing at the package level. The one function classes are too granular to support meaningful testing. I would focus higher up, where they are aggregated into something useful.

If you are working in a team with multiple developers constantly refactoring and improving things - unit tests are a must. Sometime you refactor huge bodies of code without having ever read it - good unit tests support that kind of thing. A number of times people have changed some code, the build has failed because of a unit test - and they go back and reexamine their change and go "oh yeah, didn't think of that". It saves everyone needing to be an expert on your stuff.

If your app is static and only you change the code - I agree, unit tests have less value with regard to maintenance. They still have value as little client apps - so they force you to at least think about good APIs up front. And they serve as little bits of documentation.

[SpontaneousOrder]

The benefit of unit tests is that the next developer can come along, change some code - quickly run the unit tests and be confident nothing broke. Your kind of point and click validation of a change is much more error prone. You can then have environmental dependencies break you. We've all seen a dev say "but it worked on my box".

And to your point on classes with one purpose not needing testing. You imply a class with multipurposes would need testing. The unit of encapsulation is the only thing that differs. In your world I would be testing at the package level. The one function classes are too granular to support meaningful testing. I would focus higher up, where they are aggregated into something useful.

If you are working in a team with multiple developers constantly refactoring and improving things - unit tests are a must. Sometime you refactor huge bodies of code without having ever read it - good unit tests support that kind of thing. A number of times people have changed some code, the build has failed because of a unit test - and they go back and reexamine their change and go "oh yeah, didn't think of that". It saves everyone needing to be an expert on your stuff.

If your app is static and only you change the code - I agree, unit tests have less value with regard to maintenance. They still have value as little client apps - so they force you to at least think about good APIs up front. And they serve as little bits of documentation.

And there's a strong argument that TDD (not 'unit testing'), where appropriate (which is most of the time) makes you faster anyway - so it's free.