ISerializable - Roy Osherove's Blog

I think we must be agreeing to disagree here, or we are agreeing to agree and missing it entirely in the translation.

My post was to highlight that there is an art to writing good automated tests that no tool will help you with - I deliberately didn't mention TDD as that is another art in it's own right.

If anything - tools are the problem here - a bit more focus on some really basic principles would pay off long before a few integration tests on badly written code.

When you can write a clean set of unit tests that have real value, you won't need to be writing code that is tightly coupled, nor would you want to ... or ....

Honestly Roy, would you write new code that is tightly coupled knowing you can fall back on tooling, or would you write it by nature in a loosely coupled way?  To me both have the same up front effort, the loosely coupled way pays large dividends later on (like today when we had to consider moving our application search engine to another server, which will be nearly trivial due toit all being loosely coupled already)

I think that you've found the crux of it: a path of “all or nothing”. which for most people begets “nothing”.

I like Rebecca Wirfs Brock's 'Object Design' as a book for good object oriented design -> www.amazon.co.uk/.../ref=sr_1_2

Roy,

You're absolutely right. I'm all with you on the teaching aspects. Really.

Many managers, though, couldn't give a rat's ass. And, from the project delivery perspective, they're right. They're concerned about the cost and value of these techniques in the short term.

In order to get adoption up, we need to also address the broader organizational issues.

My main concern about much of the conversation going on in the blogosphere was that it was without organizational context - as if we could really drive adoption without addressing that.

If there is a death-march project with a crappy code base, it probably isn't the best place for developers to start learning / practicing unit testing. I'm fairly sure you'd agree with that. Developers, or consultants, trying to institute unit testing there will be harder pressed to show the value these tests provide the project. Management may see these tests as "useless", possibly discounting the entire practice.

Understanding the criteria by which management assesses these techniques is critical, IMO, to driving their adoption.

Oh man. I hope you're asbestos undies are fully deployed.

One can tell by the vehement responses of many people against this idea that the idea strikes them on some sort of emotional level.

I'm really not sure what the fear is that is causing a reaction that seems out of proportion to the gvien the subject matter.  Sure, I don't want to have to come behind noobs and clean up their code, but why all the emotion?

It's very surprising to see the vehement and sometimes caustic responses to what, in a nutshell, is the idea of breaking things into more granular pieces.  Sure, it's not optimal, but to imply that one who learns to ride a bicycle with training wheels will be unlikely to then learn how to ride a motorcycle seems a bit paranoid.

Risking teaching noobs unit testing without a good understanding of OOD techniques such as SOLID, etc. is not going to place us in a worse situation than we have now where the noobs aren't even creating the first unit test.

I agree, Roy!

There has been too much puritanism around the subject of unit testing. Crappy code with tests is better than nothing. If you are going to change the way a team works, making them write tests, without any heavy introduction to OO design or TDD-or-nothing, would be the best entrance to the path leading to better things in my opinion.

If you have code with good test coverage that tests that the behaviour and results are correct you have a solid base for slowly introducing all the difficult OO concepts of loose coupling, high cohesion, open-close etc that we love to throw out there just to see people fade off to their happy place. I think this betters the chance of people learning good design patterns as a way to improve the APPLICATION for clarity, extensibility and reuse rather than learn design only as a means to write testable code. What is a testable design anyway? Making all methods public?

Good design and unit tests are both important. BUT we should start with one step at a time. Let the teams see small improvements in their work instead of an impossible wall of you-have-to-do-all-these-things-perfectly-or-you-won't-be-as-cool-as-the-ones-who-get-it...

On TDD

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #192

Pingback from  2008 October 02 - Links for today « My (almost) Daily Links

Pingback from  Dew Drop - October 2, 2008 | Alvin Ashcraft's Morning Dew

Thank you for this post. It is great have an expert post to point people towards; so far this was my favorite:

www.mtelligent.com/.../the-cargo-cult-of-test-driven-development.html

For the last five years in my Nunit/ CI presentations I have been trying to convince people to ignore techniques self-appointed 'development Gods' insist on, especially TDD. Too many developers new to Automated Developer Testing start off on a pure TDD path, predictably get frustrated and then give up on Automated Dev Testing forever.

My advice to beginners is to only write tests that obviously have much more value than the time it takes to write the test. As they become more experienced they can look at higher amounts of coverage and eventually maybe even use TDD.

Thank you for this post. It is great have an expert post to point people towards; so far this was my favorite:

www.mtelligent.com/.../the-cargo-cult-of-test-driven-development.html

For the last five years in my Nunit/ CI presentations I have been trying to convince people to ignore techniques self-appointed 'development Gods' insist on, especially TDD. Too many developers new to Automated Developer Testing start off on a pure TDD path, predictably get frustrated and then give up on Automated Dev Testing forever.

My advice to beginners is to only write tests that obviously have much more value than the time it takes to write the test. As they become more experienced they can look at higher amounts of coverage and eventually maybe even use TDD.

I've been reading this discussion with a lot of interest. I'm someone who would love to do unit testing but the barrier to entry is much too high. 90% of the code I write interacts with outside resources (database, active directory, files, etc.) I'm told you can't unit test that - those are integration tests.

When I look for information or examples on unit testing, I either have to buy into all of the methodology (TDD, SOLID, etc.)  or I'm told that what I need to test isn't unit testable.

I would love to see a good example of how I could write unit tests for the Active Record pattern. We have 100s of classes that instantiate an object that represents a row in the database with methods to insert, logical delete and update a row. The classes also have a number of shared methods that return a table of rows that match some criteria. How in the heck do I unit test that?  Once we get that data we bind it to a grid. Again, where's the unit test there? It's n-tier. The data comes from sql, via a business tier to the presentation. So if you'd like to make some progress with one company with about 50 developers, show me how to do that, and we'd get 50 people doing unit tests.

I'm tired of seeing unit test examples on how to verify that something calculates price correctly. How do I unit test that my log message made it to the database?

I could even get my management to buy into letting us have time for the learning curve, if I could come up with a plan and some solid examples that our more junior developers can model. But, until I find them, we'll just bumble along without unit tests because what's out there takes too much time to assimilate.

I think we've lost sight of our priorities in the agile movement.  Roy Osherove helps to redress the balance in his recent recent series of posts on unit testing. But my concern isn't just about making the tools approachable. The much bigger issue is...

I had a little time today, so I downloaded Isolator 5.1.

I've used TDD on previous projects, but on my latest one, there are only UI automation tests.

I looked for something to test in the project and the thing I picked definitely doesn't follow all of SOLID, among other issues, it uses the HttpContext.Current directly.

It took a little time, but I was able to get a test up and running; If I write a few more of these test, I'll be able to refactor the design to something a little more solid.

:D

Pingback from  Episode 21: Real World Development | Herding Code

There has been a fair amount of activity in the blogsphere to Roy's original post about increasing

Pingback from  Eli Lopian’s Blog (TypeMock)  » Blog Archive   » Lowering the friction of Unit testing