TDD Pattern: Composite Logic Development and Testing

My blog has moved. You can view this post at the following address: http://www.osherove.com/blog/2007/9/18/tdd-pattern-composite-logic-development-and-testing.html
Published Tuesday, September 18, 2007 8:32 AM by RoyOsherove

Comments

Tuesday, September 18, 2007 9:25 AM by Diego Carrion

# re: TDD Pattern: Composite Logic Development and Testing

Everything seems cool to me except the name of the function "HasMax10Chars".

What if tomorrow the maximum length turns 11?

Shouldn't it better to have a function called like "HasValidLength" or something similar?

Tuesday, September 18, 2007 1:10 PM by Vish

# re: TDD Pattern: Composite Logic Development and Testing

Hi Roy,

I have run into a whole lot of problems with Validate functions that returns a boolean in the past. They are not flexible enough. I have adopted creating the validation rules into a IRULE interface. The actual validation can actually be done by a delegate that is a property of the IRULE. So now the Validate function can return a List<IRULE> which will facilitate more meaning error messages etc.

Thank You,

Vish

Tuesday, September 18, 2007 2:12 PM by Steve Campbell

# re: TDD Pattern: Composite Logic Development and Testing

I have found it not really worthwhile to unit test simple field validations.  Doing so does not drive "design", so it only fulfills the "test" aspect of TDD.  That is a sign that something can better be tested elsewhere, and as it happens validations map very closely to business rules, so they can be adequately tested at a higher level (acceptance tests ala FIT).

Tuesday, September 18, 2007 2:31 PM by Jan Van Ryswyck

# re: TDD Pattern: Composite Logic Development and Testing

Hi,

Instead of using seperate methods, I'll like the approach of using "specifications" as outlined by Eric Evans and Martin Fowler:

martinfowler.com/.../spec.pdf

I'm using Tim McCarthy's Composite Specification Pattern Implementation for this.

blogs.interknowlogy.com/.../10863.aspx

This way I can keep using TDD and I can reuse specifications between several classes that have a Validate method. It also makes the business rules explicit in my model.

Let me know what you think ...

Tuesday, September 18, 2007 5:07 PM by RoyOsherove

# re: TDD Pattern: Composite Logic Development and Testing

Vish: you're assuming all "rules" have the same inputs, which might not be the case. they might also have different outputs. How would you hand;e that?

Tuesday, September 18, 2007 5:37 PM by RoyOsherove

# re: TDD Pattern: Composite Logic Development and Testing

Jan Van Ryswyck:

in essence, my implementation is that of a hard coded specification. just change the name of "Validate" to "IsSatisfiedBy" and think of each of the protected methods as leaf specifications.

the Validate method is a composite hard coded specification. the problem is still - how to you test (or rather TDD) that the correct composite specification is being built? so I want my test to fail if my IsSatisfiedBy method isn't using the leaf specifications as it should (which means it's logic is flawed).

Tuesday, September 18, 2007 5:41 PM by RoyOsherove

# re: TDD Pattern: Composite Logic Development and Testing

Diego: yeah, the name might be a bit too much but that's what refactoring tools are for.. :)

Tuesday, September 18, 2007 6:11 PM by RoyOsherove

# re: TDD Pattern: Composite Logic Development and Testing

Diego: yeah, the name might be a bit too much but that's what refactoring tools are for.. :)

Wednesday, September 19, 2007 12:24 AM by Vish

# re: TDD Pattern: Composite Logic Development and Testing

Hi Roy,

Using generic delegates gets you half the way there

And using a delegate definition like

delegate void CustomValidate1<T>(T value, List<T> others);

   delegate void CustomValidate2<T>(T value, List<object> others);

might help you out further. But yes they are hacks but i found them to be better.

And the output of rules are almost always messages that can be made a property of the rule itself or a new type for validation results can be created and a list of the broken rules or the validation result type can be returned by the validate function.

Thank You,

Vish

Saturday, September 22, 2007 8:30 PM by Avi Naparstek

# re: TDD Pattern: Composite Logic Development and Testing

Hi Roy.

I enjoyed the post - although I havn't finished viewing the entire video yet, it got me writing about my own experience test-driving composite validation methods here:

asynced.blogspot.com/.../testing-everything.html

I'd be interested to hear what you think.

Some comments about the video (so far):

1. Seems like the testable-subclass demo is stealing the spotlight away from the issue of composition.. Have you considered seperating the two?

2. It seems like you are pre-assuming a design here - specifically that you'll have a Validate() method using smaller Has6Chars(), HasDigits() etc methods. It might be interesting to demonstrate how the code evolved towards a solution rather than see how to unit-test an existing (or pre-cincieved) solution.

All the best and keep 'em coming,

- Avi

Friday, September 28, 2007 10:17 AM by Donny Darko

# re: TDD Pattern: Composite Logic Development and Testing

Hi - I must confess I am not a TDD expert, but seeing this video really had me raise my eyebrows.

The scenario is that you are developing a framework, that should be used within your company. you want to TDD the framework (which i believe is a good thing!). then you start using different patterns that allow for the framework to be testable (good), but meanwhile you make consessions with regards to your public API (bad).

I could easily see myself in a situation in which I would have to explain... yes, well... the Fx design is kinda awkward. but this was just the easiest way to test the Fx.

:-S