Egg and Gherkin is a development tool written in C# to qualify the evolvement of your software architecture within predefined limits. Controlled by the unit test framework of your choice, it gives immediate feedback when breaking architectural constraints.
Test output samples
DependencyAnalysis.DependencyException: Unapproved submodule: SubmoduleDescriptor: theeg.DependencyAnalysis.CommonAddin.Views
Unapproved submodule: SubmoduleDescriptor: theeg.DependencyAnalysis.CommonAddin.resources
at DependencyAnalysis.VerifierUtilities.ThrowDependencyException(IEnumerable violations, String format) in C:\workspace\Codeplex\DependencyAnalysis\DependencyAnalysis\VerifierUtilities.cs:Line 39.#0
at DependencyAnalysis.Internal.Verifier.VerifySubmodulesInModule(ModuleDescriptor module, IEnumerable`1 allowedSubmodules) in C:\workspace\Codeplex\DependencyAnalysis\DependencyAnalysis\Internal\Verifier.cs:Line 120.#1
at ArchitectureTests.ApprovedNamespacesTest.AllowedNamespacesInCommonAddin() in C:\workspace\Codeplex\DependencyAnalysis\ArchitectureTests\ApprovedNamespacesTest.cs:Line 47.#2
DependencyAnalysis.DependencyException: theeg.DependencyAnalysis.CommonAddin.Models.ArchitectureGraphModel.§Void BuildNodes(System.Collections.Generic.Dictionary`2[DependencyAnalysis.DataModel.ModuleDescriptor,System.Collections.Generic.ISet`1[DependencyAnalysis.DataModel.DependencyDescriptor]], Boolean, System.Collections.Generic.Dictionary`2[System.String,theeg.GraphWpf.Models.Node], theeg.DependencyAnalysis.CommonAddin.Models.GraphParameter) violates assumption 4
theeg.DependencyAnalysis.CommonAddin.Models.ArchitectureGraphModel.§Void BuildModuleTransitions(System.Collections.Generic.Dictionary`2[DependencyAnalysis.DataModel.ModuleDescriptor,System.Collections.Generic.ISet`1[DependencyAnalysis.DataModel.DependencyDescriptor]], System.Collections.Generic.Dictionary`2[System.String,theeg.GraphWpf.Models.Node], System.Collections.Generic.Dictionary`2[System.String,theeg.GraphWpf.Models.Transition], theeg.DependencyAnalysis.CommonAddin.Models.GraphParameter) violates assumption 4
at DependencyAnalysis.Internal.Verifier.VerifyThat[T](Func`3 assumption, Predicate`1 whereClause) in C:\workspace\Codeplex\DependencyAnalysis\DependencyAnalysis\Internal\Verifier.cs:Line 402.#0
at ArchitectureTests.MethodQualityTest.NumberOfParametersIsAtMost3() in C:\workspace\Codeplex\DependencyAnalysis\ArchitectureTests\MethodQualityTest.cs:Line 22.#1
Who are you?
You are a software developer. You feel a special interest in test driven development, clean code and software architecture.
What do you want?
What you can see in your every day work, is the code quality level of classes in your IDE. Automated tests can be accessed, approved and extended right away.
There are hurdles when surveying the software at the architectural level. It requires a tool first. There are quite some available. Now you have chosen for example CoolArchitecture2000 as the weapon of choice. It has a lot of features. But it has a drawback.
Anytime you want to check something has changed to the architecture, you have to start that tool.
What is wrong?
We developers are the Montgomery Scotts of our software project. Our place is the machine deck (the IDE). If we had to use the turbolifts to the bridge several times a day to see the results of our work, how long will this process last until we skip the
Who do you think is responsible for keeping a software architecture in shape?
1. The software architect?
Well the architect designs dependencies, has an overview of the whole project and bears a vision of the future structure. He suggests technologies to use. Often, he is not the one, who makes daily commits and actively changes the projects structure.
2.Can a dedicated developer be the guardian of architecture?
This will work for a prolonged time. Once he goes on holiday, no one else will invest the effort required to perform the task of keeping everything in shape. His team mates are not familiar with this task.
3. The answer must be every developer of the team is responsible.
More or less each team member has an insight at the meta-level of the project he is contributing. This is the source where the check-ins come from. And this is the only instance that can actually influence a growing sofware project.
There is often one developer, who gives the pace, but everyone knows how to keep it going. There is often a software architect, who has the vision and defines the guidelines, but everyone contributes.
What our daily tasks require are easy to use tools. There are again FxCop, StyleCop, JDepend, NDepend, dotTest, ArchStudio among others. Either they are slow, verbose, or they have to be configured or they require you to start a tool other than your IDE. -
To be honest, personally I like NDepend a lot - Now you want to verify architecture in the style of automated tests. No other tool. No need for configuration. Run inside the IDE and run the same test code during server side automated builds.
Responsiveness counts. As for any other kind of automated test the response time is vital, when you want the test to run on a regular basis. Developers need immediate feedback, whether they have broken some constraints they have not been aware of during the
time of writing a change.
Automated tests should be written in the mothers language of the developer - C++, Java, C#, Scala, Groovy, Visual Basic, whatsoever. And in a manner they do not have to think that much - with a common test framework.
This is the intention of this project. Create a static analysis tool for the architectural level of a software project. For CLR in first place, but later on ported to at least the Java Runtime. With your favorite unit test framework you setup the tests
and validations, which then can be run during continuous integration builds. Thus feedback on changed architecture comes fast and often.
Download via NuGet