--- title: "TDD Pattern: Composite Logic Development and Testing" url: "https://osherove.com/blog/2007/9/18/tdd-pattern-composite-logic-development-and-testing.md" canonical: "https://osherove.com/blog/2007/9/18/tdd-pattern-composite-logic-development-and-testing.html" published: "2007-09-18T06:32:26" updated: "2007-09-18T06:32:26" tags: ["Agile", "Agile Related", "Art Of Unit Testing", "Testing Guidelines", "Unit Testing"] author: "Roy Osherove" description: "Here's a video I made that captures my current thoughts on writing complex business rules which have lots of validation logic. Here's the scenario I show in the video: A Validate method on an object actually uses lots…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # TDD Pattern: Composite Logic Development and Testing By Roy Osherove September 18, 2007 In [Agile](https://osherove.com/blog/category/agile), [Agile Related](https://osherove.com/blog/category/agile-related), [Art Of Unit Testing](https://osherove.com/blog/category/art-of-unit-testing), [Testing Guidelines](https://osherove.com/blog/category/testing-guidelines), [Unit Testing](https://osherove.com/blog/category/unit-testing) **Historical article** · Originally published September 18, 2007; technical details may be outdated. Here's a video I made that captures my current thoughts on writing complex business rules which have lots of validation logic. Here's the scenario I show in the video: ![image](https://osherove.com/img/wb/et_blogs_rosherove_WindowsLiveWriter_TDDPatternCompositeLogicDevelopmentandTe_CC70_image_thumb_2.png) A Validate method on an object actually uses lots of smaller methods to return a result. The idea is to actually write separate tests for the underlying helper methods (which are actually individual rule checks) and a separate test for the overall logic driver (the Validate method. **Different from traditional TDD technique** This is different from the traditional way I would do TDD in that in the traditional sense, in TDD you probably would not have these helper methods but would actually write all that logic inside the validate method, and only later you would refactor the code into separate smaller methods. - TDD: Start with a simple method and refactor it into smaller methods if and when you need to while making the tests pass. - This method (Composite Logic TDD - CLTDD???): drive the creation of the separate rules as part of the TDD effort (part of the initial design). But why? Because every time I tried to accomplish the same thing with the traditional way I came up with problems thinking about my next tests. every time I would add another rules to the implementation it would break my existing tests because they had to account for my new rule. In the new method I gain full control over what the rules actually return so that I can tell the validate method - "Assume that all the rules pass, except this one". then I can go on and test things separately. here's what I mean: ![image](https://osherove.com/img/wb/et_blogs_rosherove_WindowsLiveWriter_TDDPatternCompositeLogicDevelopmentandTe_CC70_image_thumb_4.png) So the video details how you would write all this in a test driven manner. I'm personally not entirely happy with it and i think the technique is still rough around the edges (takes time to learn, not very intuitive etc..) but it's currently the only way I could come up with to test the logical driven separately from the individual rules it uses. **Separation of concerns** The thing I like about the end result is that the individual rules methods (HasDIgit() etc..) can be coded and tested independently from the logic that uses them. much like separating a call to a web service from the actual web service implementation and testing them separately. **Your input is welcome. I'm looking for:** - Giving a proper name for this technique\\pattern (the XUNit test patterns book calls the pattern "Test Specific Subclass" with the variation of "Behavior changing subclass"   but what I'm doing is a pattern for TDD that tests a composite logic piece of code. what should we call this technique? - Tell me where I'm missing something in the technique that could lead to potential problems - tell me if you think you have a better way of accomplishing this (in TDD or not)  Here's the video, 44 minutes.(the demo of the validate method starts at minute 21) Embedded Flash media from the original post is no longer playable. in the video(you can also [download it 57 MB](http://files.osherove.com/downloads/video/TDDConstraintTesting.wmv)): - understanding the problem - the different kinds of tests for this problem - a simple demo of the extract and override pattern - the full demo of using the Validate method [here are the slides](http://files.osherove.com/downloads/Video/TDDCompositeRules.zip) for this video. ## Lessons on this topic - [Testing Complex Validation Knowledge using Extract & Override](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-master-class-in-net/testing-complex-validation-knowledge-using-extract-and-override/) · The Art of Unit Testing & TDD Master Class in .NET - [Extract And Override With Validation Logic](https://courses.osherove.com/courses/legacy-code-hero/extract-and-override-with-validation-logic/) · Legacy Code Hero ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Sep 21, 2007 ### [XUnit.NET aims to be the Next NUnit, but it's too soon](https://osherove.com/blog/2007/9/21/xunitnet-aims-to-be-the-next-nunit-but-its-too-soon.html) - Sep 18, 2007 ### [The Art Of Unit Testing - Help me choose a book cover](https://osherove.com/blog/2007/9/18/the-art-of-unit-testing-help-me-choose-a-book-cover.html) - Sep 16, 2007 ### [Mocks and Stubs - The difference is in the flow of information](https://osherove.com/blog/2007/9/16/mocks-and-stubs-the-difference-is-in-the-flow-of-information.html) - Sep 13, 2007 ### [Throw-Away Tests Vs. Tests that Last](https://osherove.com/blog/2007/9/13/throw-away-tests-vs-tests-that-last.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/