csDoc.IsAutoGeneratedCode()) return;
element.Name, element.LineNumber);
asIVisitor;
rules on your projects. Style cop will automatically look for assemblies in the directory and pick up the new rules for your team.
CQRS is an object oriented architectural pattern built on the principle that every method should either be a command that performs an action, or a query that returns data to the client, but not both.
A typical CQRS scenario involves 2 DB’s, a write DB which is used to store transitional data for long running processes. For a process where a service expects multiple messages, it needs a way to temporary store data before the all the messages arrives. For e.g. to make a customer a preferred customer needs an approval from the management, which takes some time to process the request. The service will need a temporary storage for the preferred customer state change request till the approval comes. The write DB is used to store these kinds of data. The Read DB is not updated till the approval comes.
When the approval finally comes, the service will take the customer information from the write DB, complete the registration process and write it to the read DB. At this time, the temporary customer information in the write DB has done its job and can be removed from the write DB. For simpler process such as change customer first name, the change can be written to the read DB right away. Writing to the write DB is not required because there is no temporary data in this case.
This simple approach brings following benefits (from Rinat Abdullin’s blog)
This blog is an attempt to implement the principles of CQRS in a very simple way, for demonstrating the concepts of CQRS like:
When you start to solve a problem in TDD, one of the questions that most of the developers have is about the correct place to start testing the code.
Is it better to start with a high level functional test (Outside-In) at a user story and drill down into the low level tests as you progress or to come with an initial low level design and then start writing tests from the lowest component (Inside-Out) in the design and progress to the higher level components?
A short answer would be that it depends on your / team’s coding preference or approach.
If you’re not sure how your code should look like or how it will interact or communicate with other parts of your system, it’s better to have a small design discussion with the team to identify the best possible design solution and start with the low level component and let it evolve as you write more tests.
But if your design already exists (Layered approach, where the layered components are identified like controllers, services, repositories etc.), you can start with the Outside-In approach.
As you see, Inside out testing implies a developer would probably consider the high-level design and break them up into low level components that interact with each other to provide the desired functionality. The developer thinks about how each component will be used by its client components and tests accordingly.
The advantage is that the team can deliver working software quickly as they have started with a proper design in his mind. However, since the code delivered was not written considering the high level user requirements, it may produce code that doesn’t go well with the YAGNI principle and also have a risk of not meeting the actual functionality.
In the Outside In approach, the part of system that has the closest correlation to the user requirements are tested first, guarantees that the critical parts of the application is tested first. Here the focus is more on how the user interacts with the system, rather than how the components interact with each other. The test cases generated hence supports the usability of the system.

Enabling continuous quality is a key focus area of Update 1for VS2012. With the release for Update 1, code coverage results are available for automated test cases as well as manual tests. You can now record your coded ui tests and analyze the code coverage for these tests. Using the test explorer, you can now analyze the code coverage results for a group of tests or a single test.