Test Driven Development vs working at the right level of abstraction

Sadek Drobi’s Blog » High abstraction level of DSLs to reduce the testing burden?

Fri, 19 Oct 2007 17:10:58 GMT

Pingback from Sadek Drobi’s Blog » High abstraction level of DSLs to reduce the testing burden?

re: Test Driven Development vs working at the right level of abstraction

Andres Aguiar — Tue, 20 Dec 2005 19:50:00 GMT

Hi Rob,

Yes, you are probably right, it's a bad example, but don't focus on the example ;)

If it's a simpler validation (like a date range) I'll also want to perform it in several places.

I think the workflow sample is better. Would you test a Workflow diagram? Would you test rules written for a business rules engine? How?
If they are difficult to test, they must be disregarded as a good solution?

re: Test Driven Development vs working at the right level of abstraction

Rob Park — Tue, 20 Dec 2005 19:26:00 GMT

As a fulltime TDD'er, it seems to me your design is flawed. Shouldn't the inventory check be a business function for the business tier only? That would reduce duplicated logic and allow for a single unit test to cover the logic?

re: Test Driven Development vs working at the right level of abstraction

Vikram Lashkari — Tue, 13 Dec 2005 10:59:00 GMT

Hi guys,
This was really a gread dicussion about the Test Driven Developement vs Working at right Level of abstration.. Sharing my experience on this i can say that I have always followed the Test Driven Development strategy..

Few of my work u can see there

http://www.blueunplugged.com
http://l8shop.net
http://www.victorianplumbing.co.uk
http://www.spudmobile.co.uk
http://www.mpa3000.co.uk

Hope u will like my work, u can mail me for any suggestion vikram_lashkari@yahoo.com

Thanks again
Vikram Lashkari

re: Test Driven Development vs working at the right level of abstraction

Cory Foy — Fri, 09 Dec 2005 04:43:00 GMT

Hi Andres,

I see now what you're asking. There have been discussions on the TDD mailing list about Test-Driving code generated from a Wizard and other generation frameworks.

I think it comes down to how much you want to trust the tool you are using, and the pain points you are experiencing. So, with your WWF example, my question would be, what problems have you run into with it? When you have to change something, how can you know that nothing broke, or how can you know what is going to break?

I guess for me I sketch out a design or prototype, then use TDD to fill in the details, being cautious to allow my code to evolve where TDD is leading me without sacrificing where I need to end up. I like to work in small chunks so that I can get rapid feedback about whether it works, and also so that if it doesn't, I'm Ok with throwing it away.

I can't see that holding true for things like WWF. Again, I haven't seen it, but I have seen some Speech Server stuff, and the workflow generation in it. It's cool. But how do you test it?

And maybe the answer is that you don't. You trust the tool.

re: Test Driven Development vs working at the right level of abstraction

Gishu — Thu, 08 Dec 2005 06:43:00 GMT

I would still use TDD :)
IMHO it helps me to check all my assumptions rather than take it on faith or the success of one execution path.
I haven't had much exposure to DSLs but for me TDD helps my design/software/system talk back to me as to what I need to do next/ do better.

re: Test Driven Development vs working at the right level of abstraction

Cory Foy — Wed, 07 Dec 2005 13:29:00 GMT

I think the hard thing is that you aren't learning TDD with a background C#, you are learning a new language that has familiar syntax. Meaning, you have to learn the new shortcuts that work for you, and also that it will be slower going at first.

I wrote a little more on my site in response to this at http://www.cornetdesign.com/2005/12/guitar-lesson-tdd-analogy.html

re: Test Driven Development vs working at the right level of abstraction

João Pedro Martins — Wed, 07 Dec 2005 00:07:00 GMT

I am currently in a project where NUnit tests writen in C# are being used to test BizTalk Orchestrations (=DSL). A conceptual mess, but it seems to work.

re: Test Driven Development vs working at the right level of abstraction

Ron Scott — Wed, 07 Dec 2005 00:07:00 GMT

It may look similar but it is actually very different. In the first case, your actual implementation code is ensuring that an invalid situation cannot happen. In the second case, your unit test is making sure that your implementation code enforces business cases properly. Unit tests don't test business logic! Unit tests ensure that your application handles business logic properly. The two snippets you posted are complementary, not competitive.

re: Test Driven Development vs working at the right level of abstraction

Scott Bellware — Tue, 06 Dec 2005 23:37:00 GMT

> If your abstractions suck, then your tests
> will have trouble doing what you want.

If the design pressures are applied from the client code in the test suite, and a given test is in place before a given code path is implemented, how do tests have troubling "doing what you want"? I would agree that poorly-written tests suffer from this kind of thing, but crappy code is crappy code, be it test code or functional code.

I don't experience this in my TDD practice, but I do see how this can happen with end-of-line QA-oriented testing done in waterfall.

It's really hard to come out at the end of TDD with abstractions that suck. Your fist cut at the abstractions might suck, but that's just the nature of software development. TDD helps surface the realities of why a given design might suck rather than allow the suckiness to go unnoticed causing optimal design phase shifting to cascade through a codebase in such a way that can rarely be tracked to its source.

TDD is indeed all about challenging design abstractions, but in doing so, it provides a path through to the application of more optimal solution designs for the given problems.