This is not the first time I came back to automated builds and re-evaluate how they are done. This time, I wanted to capture several things at the same time:
1. Specifications and Integration tests have to reside within the same project with the SUT, so that there's no need to maintain 2 separate projects structures and keep them in sync.
2. Ensure that visually we be determined if a class has Specifications or/and Integration tests (SomeClass.cs, SomeClass_Specs.cs, and SomeClass_Integration.cs)
3. Reuse the existing scripts generated by VS.NET for us
The last point is the key. Since VS.NET 2008 project files are actually MSBuild scripts. Good or bad, that's not important. What is important is that information about project and how to compile it already exists and we should be able to re-use it and not re-invent the wheel.
NAntContrib has MSBuild task. Sadly, it says that parameter is the solution file. In reality, it can be just a single project file, after all, it's just an MSBuild script. By running this task on an MSBuild file we can get all the work done for us. What we missing, is the ability to filter out Specs and Integration tests when we don't need those.
What would it look like? Example:
build –D: build.production.deployment=false
would compile all the specs/integ. Tests into the assembly
build –D: build.production.deployment=true
would not compile all the specs/integ. Tests into the assembly
How this would be done?
In nant script we would have something like this:
1: <target name="compile.app" depends="prep">
2: <msbuild project="${app.proj}">
3: <property name="Configuration" value="${build.configuration}"/>
4: <property name="OutputPath" value="${app.compile.dir}"/>
5: <property name="ProductionDeployment" value="${build.production.deployment}"/>
6: </msbuild>
7: </target>
In project file, we would have to “filter” things that are not always will go into assembly in msbuild fashion:
1: <ItemGroup>
2: <Compile Condition="$(ProductionDeployment) == 'false' " Include="**\*_Specs.cs" />
3: <Compile Condition="$(ProductionDeployment) == 'false' " Include="**\*_Integration.cs" />
4: <Compile Condition="$(ProductionDeployment) == 'false' " Include="**\Infrastructure\Testing\*.cs" />
5: <Compile Include="Properties\AssemblyInfo.cs" />
6: <Compile Include="SomeComponent.cs" />
7: <Compile Include="IContract.cs" />
8: </ItemGroup>
This would allow Visual Studio .NET to show the files, but have a conditional compiling. Reference would follow the same route (at this point they are always copied, but the result assembly is not referencing them if we set ProductionDeployment to true), I still have to figure out how to express that properly. Not sure how to apply same condition on the <Reference> elements. Ideas?
Bottom line - nant, rake, powershell, msbuild - it's all good. What is missed is the fact that we have assets we can take advantage, and not redo things that already there.
Today one of our team members brought up a valid question - how do I know that my SUT (system uder test) packages the primitive parameters (username and password) and sends into dependency object as a DTO. Maybe instead of packaging into DTO the primitive values it packages something else by accident. The proposed solution was a dedicated Factory per each DTO (contract and implementation). For testing purpose it was great, but from the design perspective this is an absolute no-no. Lets review what we have and what we want to have.
Have:
- A SUT that leverages a dependency to perform a task
- Communication to SUT is done with primitive types (2 strings in this case)
- Dependency requires primitives to be sent as a DTO
Want to have:
- Test on SUT that does interaction testing with dependency
- Verify that parameters provided to SUT are propagated into dependency and no surprises with that take place
How to achieve what we need? We have to ensure that whatever dependency was called with is matching what the SUT was invoked with. It doesn’t mean we have to have a factory. Here’s an example:
1: using Library.Infrastructure;
2: using Rhino.Mocks;
3:
4: namespace Library
5: {
6: [Concern(typeof(ServiceContract))]
7: public abstract class ServiceContract_Specs : ContextSpecification<IServiceContract>
8: {
9: protected IDomainService domainService;
10:
11: protected override IServiceContract create_system_under_test()
12: {
13: return new ServiceContract(domainService);
14: }
15:
16: protected override void establish_context()
17: {
18: system_under_test = create_system_under_test();
19: }
20: }
21:
22: public class When_service_is_asked_to_validate_a_user_with_provided_user_name_and_password : ServiceContract_Specs
23: {
24: private const string username = "username";
25: private const string password = "password";
26:
27: protected override void establish_context()
28: {
29: domainService = dependency<IDomainService>();
30: domainService.setup_result(x => x.ValidateUser(Arg<UserDto>.Is.NotNull)).Return(true);
31: base.establish_context();
32: }
33:
34: protected override void because()
35: {
36: system_under_test.Validate(username, password);
37: }
38:
39: [Observation]
40: public void Should_leverage_domain_service_to_validate_a_user()
41: {
42: domainService.was_told_to(x => x.ValidateUser(Arg<UserDto>.Matches(
43: dto => userdto_details_match_username_and_password(dto))));
44: }
45:
46: private bool userdto_details_match_username_and_password(UserDto dto)
47: {
48: return dto.Username.Equals(username) && dto.Password.Equals(password);
49: }
50: }
51: }
The underlined code is verifying what we “want to have” without having a factory in place. A simple predicate replaces requirement in Factory per DTO just for testing needs.
I am opened for discussions, but pretty sold on the fact that Factory per DTO is a waste of time.
Update: updated the establish_context to setup a proper result (domain service, ValidateUser behavior is returning a value).
This is an interesting book to read in case your reading queue is empty
and you want to brush up some aspects of C# (2/3). I can't recommend this book as a general reading, as it's way too narrowed to specific subjects (or implementation of those). Saying this, I really loved the introduction into expressions and functional pieces in C#. It gives you the hint what's going on, leaving a taste of more to read.
PS: Ismaël, thank you for letting us have it ;)
I am happy to welcome David Morgantini, who has joined our team. Adding another solid developer into our team is definitely the right step. This is going to be an exciting journey for all of us.
Good luck, David.
So today is the day. I am 31 and a new iteration in my life has started. What are the features I am trying to achieve in this one? A few:
- Improve in my profession
- Become better developer
- Lead by example
- Become more active
- At work place
- Community (*)
- Overcome a few of my own "border bullies" that I have started to face recently, but not done yet
And more than ever - "Never give up, never surrender".