Active Conventions with NDependJune 28, 2008
Suppose we want to enforce a BDD naming convention for every SetUp method. Such methods should be named Establish_context. The following CQL constraint reports those methods that are not named consistently:
// <Name> // NUnit SetUp methods that are not named consistently. // </Name> WARN IF Count > 0 IN SELECT METHODS FROM ASSEMBLIES "MyProject.Domain.UnitTests", "MyProject.Infrastructure.UnitTests" WHERE HasAttribute "NUnit.Framework.SetUpAttribute" AND !NameIs "Establish_context()"
Lets have another one. A while ago, I wrote this post about how WCF gave me this weird exception after I forgot to put a DataContract attribute on one of my DTO classes. Lets write another active convention for that:
// <Name>Data contracts without a DataContract attribute.</Name> WARN IF Count > 0 IN SELECT TYPES FROM NAMESPACES "MyProject.MyServiceContracts.DataContracts" WHERE !HasAttribute "System.Runtime.Serialization.DataContractAttribute"
Now here comes my personal favorite. Being the huge DDD adept that I am, I want to enforce that the domain is the core, the centerpiece, the kernel as you may of my application. I don't want it to have any dependencies to other assemblies in my application, especially not the infrastructure assembly.
// <Name>Domain is directly using the infrastructure</Name> WARN IF Count > 0 IN SELECT METHODS FROM ASSEMBLIES "MyProject.Domain" WHERE IsDirectlyUsing "ASSEMBLY:MyProject.Infrastructure"
It can't get any easier than this, now doesn't it? This is actively enforcing Separation of Concerns. Another way to have a convention about this is the following:
// <Name>Domain-Driven Design convention</Name> WARN IF Count > 0 IN SELECT ASSEMBLIES WHERE AssemblyLevel > 1 AND NameIs "MyProject.Domain"
This means that my domain assembly can only have a reference to the .NET framework assemblies and nothing else. This gets my geek heart pounding.
Imagine the possibilities if you incorporate this with your daily and continuous integration builds. Pure software quality assurance if you ask me.
If you and your team want to learn more about how to write maintainable unit tests and get the most out of TDD practices, make sure to have look at our trainings and workshops or checkout the books section. Feel free to reach out at email@example.com.
Jan Van Ryswyck
Thank you for visiting my blog. I’m a professional software developer since Y2K. A blogger since Y2K+5. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Past organizer of the European Virtual ALT.NET meetings. Thinking and learning about all kinds of technologies since forever.
Watch The Videos
- Behavior-Driven Development
- Concurrent Programming
- Continuous Integration
- Core Skills
- Design Patterns
- Domain-Driven Design
- Event Sourcing
- Fluent Interfaces
- Functional Programming
- Object-Relational Mapping
- Open Source
- Software Design
- Test-Driven Development
- Visual Studio
The opinions expressed on this blog are my own personal opinions. These do NOT represent anyone else’s view on the world in any way whatsoever.
Thank you for visiting my website. I’m a professional software developer since Y2K. A blogger since Y2K+5. Author of Writing Maintainable Unit Tests. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Thinking and learning about all kinds of technologies since forever.