Course in Software Engineering

[SpontaneousOrder]

I've been wondering how long it would take until someone brought up design. How long will it be before we visit the precursors to design and their relationship to success/quality?

Given TDD suggests starting with a single test, it would be nice to see an example.

There are many levels of software development/engineering. From Application to Component. Is TDD suitable for all aspects of development?

TDD is hard to do with legacy code - it might not even make sense if you just want to make a minor tweak, as the design is already concrete.

TDD doesn't always add value when you're not really sure what you're doing yet. Like when you have a rough idea but you're doing some exploratory tinkering to try to shake out a more complete mental image if what it is you're actually trying to achieve.

TDD generally works at the unit level (a single method up to a small handful of classes working together, encompassing a small unit of functional responsibility). Much of the benefit comes when your unit is more than a single class because design is all about collaboration.

Naive TDD can sometimes lead to a mock/stub obsession - see David Heinemeier Hansson 'TDD is dead' debate with Martin Fowler & Kent Beck. DHH has the wrong end of the stick, and it's not that surprising because as far as I can gather (i'm not expert in rails) rails is inherently very difficult to unit test - and he invented rails.


Beyond tdd similar principles work well at higher levels, with things like ATDD already mentioned, and BDD which focuses on behaviour too, but is really aimed at having a living specification that specifies bahaviour according to inputs and conditions which is understandable to everyone in the business. Works nicely with a domain driven design (DDD) approach and it's idea of a 'ubiquitous language'.

TDD isn't a process that will work well, though, if you follow it blindly. When learning it people suggest literally following the process without much brain input, because it's a disciplin that needs repetition to become a habbit. But beyond learning the basics you need to follow this process of tiny increments followed by refactoring, with mindfulness of good SOLID principles, etc.

You should, though, end up in a situation where every single line of your core domain code has a spcific reason to live - encapsulated in a test that would fail if it didn't. This is a good measure of whether you're doing it properly or not, as when you don't test drive your code (lets assume you write unit tests afterwards) then you can't know this.

[SpontaneousOrder]

Why so angry in your comment? TDD tools for example I use resharper to run unit tests and use Moq t mock dependencies etc. As I said if I'm writing something more complex I spell out what the code does in comments before I write it or I will sit down and design the code.

Because there is no such thing as a 'TDD tool'. I'll agree that some IDE features or frameworks can make TDD easier in the same way that a hammer makes hanging pictures easier - but a hammer is not a picture hanging tool. Like i said - TDD is not about testing.

[woohoo]

That's exactly what you don't want to be doing. Strive to work at the highest level of abstraction that you usefully can. That way, you decouple yourself from details, and can move faster.

The unit tests can be done to document a contract of how the code *should* be used, not how it *is* being used.

I don't mind looking at unit tests to see how the unit test has been written. But I would look at how the code is being used in real life to understand it. TDD as documentation is fine if that's the reason you are writing it but for me I would go back to how the code has been designed and wonder why it's not following an established pattern.

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.

The only time I've practically used it is when writing something complex and I've used the TDD tools to put together some tests so I could easily test/write/test without going through a screen or page.

If you get mileage out of TDD that's great but for me it offers pretty minor benefits for design or testing.

[woohoo]

Because there is no such thing as a 'TDD tool'. I'll agree that some IDE features or frameworks can make TDD easier in the same way that a hammer makes hanging pictures easier - but a hammer is not a picture hanging tool. Like i said - TDD is not about testing.

You understand that your comment is nonsense. Plus, TDD can be about testing as well as design.

[SpontaneousOrder]

You understand that your comment is nonsense. Plus, TDD can be about testing as well as design.

It is less nonsensical when you stop conflating TDD with unit testing your code.

[woohoo]

It is less nonsensical when you stop conflating TDD with unit testing your code.

Right, well I'm off to hang a picture, I'm not going to use a tool, just a hammer. FFS

[SpontaneousOrder]

I can't see any reason to add unit tests to this project.

The primary reason to unit test your code (not talking about TDD here) is NOT to check that it works.

People write unit tests to make their code maintainable.

If we knew the code would never change then we could literally build it out of literal spaghetti if we wanted (sounds expensive though), and noone would give a tulip.

[SpontaneousOrder]

Right, well I'm off to hang a picture, I'm not going to use a tool, just a hammer. FFS

This is you...


me: "hanging pictures isn't about hammering, but you need to hang pictures if you want a pretty lounge - and a hammer can be useful to do that."

you: "I don't agree... I use a hammer sometimes to build a new front porch, but apart from that I don't see why i'd ever need to hammer a kitchen cupboard."

me: ""

[woohoo]

This is you...


me: "hanging pictures isn't about hammering, but you need to hang pictures if you want a pretty lounge - and a hammer can be useful to do that."

you: "I don't agree... I use a hammer sometimes to build a new front porch, but apart from that I don't see why i'd ever need to hammer a kitchen cupboard."

me: ""

More nonsense, please stop, you really are embarrassing yourself.

[SpontaneousOrder]

More nonsense, please stop, you really are embarrassing yourself.

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