Category: TypeMock

Agile Architecture.

Last week I presented a webinar about Agile Architecture and I got an unexpected positive feedback from it. First it was unexpected because I didn’t expect to get lot of people interested in this particular topic. Second it was unexpected because I am still at the beginning of my teaching career and presenting webinars so I am not so good yet to keep the audience interested for 60 min.

Btw, considering the result of the webinar, I decided to post the video of the webinar (thanks to the guys of Typemock!) and a short introduction to Agile Architecture.

Agile Architecture webinar:

Update: slides available on SlideShare.

Agile architecture

What is Agile Architecture? It is a methodology that follows the Agile guidelines but differ from some aspect of its process.

At this web address: you can find probably the official website of this Agile methodology, even if you may find a lot of interesting discussions and articles here and there on the web, just google “Agile Architecture”.

Another interesting web site is where you can find tons of information about Agile Modeling and Agile Architecture. (If you watch the webinar I spoke about both of them).

Finally, if you want just to read a quick article and understand the overall process of Agile Architecture, I found this article of J.D. Meier very helpful: “How to design with Agile Architecture”.

TFS Template

I got various requests about the TFS and Dashboard templates I used during the webinar. I got them from the beta of Team Foundation Server 2011, available here. You need to customize the process to fit better Agile Architecture methodology. I am planning to prepare a custom template for TFS 2011 as soon as the SDK will be finalized.

Q/A from the webinar

Below is a short list of some of the most interesting Questions and Answers I got during the webinar. I am posting them here because during the webinar I wasn’t able to read them because I am using the MAC version of GoToWebinar.

Q: Acceptance Tests should have been written before the model.

Not really, if you adopt the strict TDD all the acceptance tests should be written before, but when you envision the architecture, it is too early to write acceptance
tests. When you start the iteration and you have your requirements defined, you may start to model against the acceptance criteria for that iteration. But remember
that the modeling part should be light enough to provide value for the next step.

Q: the functions of the architect are clear, but it is not clear how these functions are intended to fit into the Sprints.

The sprint is composed by three parts, modeling, brainstorm and coding. The architect will perfectly fit into each of this phase. I think I have explained this
concept during the webinar, but just to be sure. During modeling and brainstorm the architect should help with his knowledge and collaborate in the modeling, during
the coding he should be an active coder too and contribute to the technical decisions providing knowledge and expertise.

Q: Can you elaborate on what you mean with the “design phase”?

Ok, during the first iteration, the envision, there is a light design phase. You should design some scratches of your envision, representing the architecture and the UI, but you should not invest too much time.
Design phase while modeling means adopting UML to design your models.

Q: How does your “Iter: 0” relate to the PO, backlog and sprint planning?

Ah ah, interesting. The envision or iteration 0 is tricky to fit into SCRUM. Take the classic meter to measure an iteration, like 1 or 2 weeks. Inside this timeframe you should have enough space and time to prepare the necessary analysis and mocks required by next steps. So you may consider iter 0 like a beginning sprint.

Q: Couldn’t the use-case diagram be enough for the modelling phase? I’m interested in hearing your reasoning because I’m currently in this situation in my current project. What level of detail is enough when it comes to architecture that lets developers use their brain and problem solving power?

No, the use case is not enough because it may incur into personal interpretation. With the use case and the acceptance you and your team are ready for the modeling phase, where you create the architectural style for that feature. The modeling should be enough to represent the current feature and it should not be implemented, the implementation occurs in the next phase where you apply TDD against the model discussed in the previous part. It is hard to keep the model the blueprint of the code and often it doesn’t provide value. It is important that the model represents what you are delivering.

Q: Does the Process workflow you describe impact the philosophy of embracing change? How can we perform radical change when we get a bigger up-front model?

No, it doesn’t because Agile Architecture pretends the flexibility into your model. Model just enough to represents the feature and remember that you can always come back and re-model and re-factor. Embracing Agile Architecture will force you to have a dynamic more agnostic and flexible model than using a classic architecture approach.
Why would you get a radical change request with a radical model upfront? Of you adopt Agile you should structure these changes into small iterations.

The envision phase is the most critical, you or the architect need to understand what the stakeholder wants from your team. If you get that, you are in a good starting position.
The big mistake is to take too much for the envision, which is not the modeling phase. Mocking out your application doesn’t mean to model everything, so the envision should take few days, at most one week. If it takes more you may have some smells in your team: lack of requirements, lack of business knowledge, lack of technical knowledge.
Remember that every iteration has a modeling phase and a brainstorm phase, so you may move back to the envision and adapt it to the new requirements.

Speaking about Agile Architecture

The 9th of May 2012 at 2 p.m. (GMT +1) I will speak about Agile Architecture. The webinar will be registered and hosted by Typemock.

This is the address to register:

Below is the Agenda and you are still in time to add some little changes:

What is Software Architecture
• What is Agile development
• How they can live together?
Discover principles of Agile architecture
• Lifecycle and process
• Modeling and development
• The right solution for the right problem
• How to deliver quality with (TDD)

If you want to listen about this topic or more feel free to drop me an e-mail (using my blog contact form) and I will be more than glad to expand it during the webinar. Of course it has to be something related to Agile Architecture … Winking smile

If you want to read more about it I would suggest you the following articles:

Agile Architect principles

J.D. Meier “Agile Architecture”

PS: I guess if we are numerous I may get a Typemock license available for free to one of the attendee. Winking smile

TypeMock tutorial #03. Control behaviors.

Note for purists: In this tutorial I am showing you a simplified example of a Unit of Work and a Repository, please do not care about the complexity or simplicity of these objects but look at the TypeMock implementations.

We are now at the third post of this series and I found out that there are a lot of readers interested in learning TypeMock, which means that series will have to continue!

Last time, we have created some object’s mocks using TypeMock but they were simple Value Objects with nothing or very few business logic in it. This time I want to show you how you can control the behaviors of a mock so that you do not have to control or fake the entire object if you are testing a single method.

Testing a IUnitOfWork

I do not know if you have already created a data layer in your career of software developer; if you did not, you can have a look at one of my tutorials or books about layering an application.

First of all we have a Unit of Work, which allows us to “Save”, “Update” or “Delete” the object we are passing it using a generic signature. The contract for a Unit of Work is represented by the following image:


As you can see we have a simple interface with three methods and we still do not have an implementation for it but we have some expectations that we would like to pre-test using a mock in order to be sure that the next step will be properly handled by TypeMock.

The pre-requisite is that every entity in our domain has some properties inherited by a base class DomainObject; these properties can tell us the ID of the entity, if the entity is new, modified or deleted.

The following object represents the base class for a domain entity.


The 3 properties are of type boolean while the UniqueId is of type Guid, so by default we will have a Guid.Empty value and after we mark dirty or updated the object we should have them populated.






Test the interface

If we test the interface we can start by writing three different expectations like the three following snippets:

Mark a new entity
  1. [Test]
  2. [Category(“DataLayer”)]
  3. public void CanMarkANewEntityToNewAndChangeItsId()
  4. {
  5.     Person person = Isolate.Fake.Instance<Person>();
  6.     IUnitOfWork uow = Isolate.Fake.Instance<IUnitOfWork>();
  7.     uow.MarkNew(person);
  8.     Assert.That(person, Has.Property(“UniqueId”).Not.EqualTo(Guid.Empty));
  9.     Assert.That(person, Has.Property(“IsNew”).True);
  10. }

And as soon as we run this test it simply fails because of course TypeMock is not able to properly mock the method MarkNew as we did not instruct it on how to do it …

The solution in this case is pretty straightforward, before invoking the MarkNew<T> method we need to teach to TypeMock what is our expectation for this method when we add a Person object to it.

  1. Isolate.WhenCalled(() =>
  2.     uow.MarkNew(person))
  3.     .DoInstead(callContext =>
  4.                    {
  5.                        var p = callContext.Parameters[0] as Person;
  6.                        p.UniqueId = Guid.NewGuid();
  7.                        p.IsNew = true;
  8.                        return p;
  9.                    });
  10. var expectedPerson = uow.MarkNew(person);

In this case we have informed TypeMock that when we will call the method MarkNew<T> passing as a generic paramenter the Person object, it will have to modify the person object and return it with a new ID and the IsNew property populated.

Another way to do that is to use the WillReturn method of TypeMock that can be used, like in this case when we have functions and not void methods.

  1. person.UniqueId = Guid.NewGuid();
  2. person.IsNew = true;
  3. Isolate.WhenCalled(() => uow.MarkNew<Person>(person)).WillReturn(person);
  4. var expectedPerson = uow.MarkNew(person);

In the same way we can test that the method may also return an unexpected exception, so we can inform TypeMock to force the mock interface to throw an exception.

This section of type mock is called Controlling method behaviors and you can find a detailed documentation about it at this address:

controlling methods

In the next tutorial we will see how to customize a chain of mockup object and faking the methods so that the IUnitOfWork will be used as a dependency for a Repository class.

If you want you can also download the code of every tutorial at this address on Codeplex:

Winking smile

Encrypted string of the week: IHcKGzESRVs=
using Blowfish CBC 64bit

TypeMock tutorial #02. Object creation.

In this new  part of the TypeMock series I am going to show you how to deal with objects and classes in general, how you can create them and what are (honestly aren’t) the limit of TypeMock on dealing with objects.

First of all I have just drawn down a little domain that I have added to the demo application. I am planning to upload this demo the next week on so that every geek reading this blog can just go there and download the source code.

The Demo domain

The domain is a very simple one, we have an abstract base class called Person, then we have two concrete classes, an Employee and a Customer that right now do not have any differences (we will see in the next tutorials why we have two different concrete classes) and then we have a value object Address that is composed only if we provide to it a parent Person object in the constructor. The Person entity exposes a read-only IEnumerable collection of Addresses, so in order to add or remove an address we must use the provided methods AddAddress and RemoveAddress.

The following picture shows the corresponding class diagram of this small domain.


These are the most important piece of code that you may be interested in:

Read-only collection Addresses
  1. private IList<Address> addresses = new List<Address>();
  3. public IEnumerable<Address> Addresses
  4. {
  5.     get { return this.addresses; }
  6. }
  8. public void AddAddress(Address address)
  9. {
  10.     if (this.addresses.Contains(address))
  11.     {
  12.         throw new InvalidOperationException(“The address is already in the collection.”);
  13.     }
  14.     this.addresses.Add(address);
  15. }
  17. public void RemoveAddress(Address address)
  18. {
  19.     if (!this.addresses.Contains(address))
  20.     {
  21.         throw new InvalidOperationException(“The address is not in the collection.”);
  22.     }
  23.     this.addresses.Add(address);
  24. }


Constructor of an Address obj
  1. public Address(Person person)
  2. {
  3.     Person = person;
  4. }
  6. public Person Person { get; private set; }

As you can see we have few things that need to be tested but in order to do that we have to create new instances of these objects in order to run our tests, which is pretty verbose and boring

Create the test project

The first step is to create a new Visual Studio 2010 Visual C# class library project and call it TypeMockDemo.Fixture and add the following references to it:


The references are pointing to:

  • my TDD framework nUnit (you can work with any TDD framework but I personally found nUnit to be the best out there …)
  • TypeMock assemblies, installed in the GAC of your machine
  • The TypeMockDemo project (the one we have the domain entities in)

Now we can start to create the first class fixture and verify that we can create a new Person, a new Employee and a new Customer. But hold on a second! How can we mock an abstract and two sealed class with a mocking framework? We simply can’t if we are not using TypeMock … Winking smile

Create new abstract and Sealed
  1. [Test]
  2. [Category(“Domain.Isolated”)]
  3. public void AssertThatCanCreateANewPerson()
  4. {
  5.     Person person = Isolate.Fake.Instance<Person>();
  6.     Assert.That(person, Is.Not.Null);
  7. }
  9. [Test]
  10. [Category(“Domain.Isolated”)]
  11. public void AssertThatCanCreateANewEmployee()
  12. {
  13.     Person person = Isolate.Fake.Instance<Employee>();
  14.     Assert.That(person, Is.Not.Null);
  15. }
  17. [Test]
  18. [Category(“Domain.Isolated”)]
  19. public void AssertThatCanCreateANewCustomer()
  20. {
  21.     Person person = Isolate.Fake.Instance<Customer>();
  22.     Assert.That(person, Is.Not.Null);
  23. }

Looking at the code we have introduced the new method Isolate.Fake.Instance<T> that is coming from TypeMock. With this method we can simply inform TypeMock that we want it will create for us a Proxy of the object we want to mock and it will return a derived class of the tested one, even if we are mocking a sealed class.

If the class is sealed TypeMock will create a new instance of the original object while if the object is abstract, TypeMock will create a proxy version of that object. Same thing will be done for all the child properties, complex or not …


That’s simply wow, we just used two lines of code to create a mockup and test it.

Now let’s move forward and let’s verify that we will not be able to add the same address twice and to remove the same address twice from a Person object.

Working with Instances or Proxy?

First of all we start to create this simple test but the result is not the one we expect …

Test a collection
  1. [Test]
  2. [Category(“Domain.Isolated”)]
  3. public void AssertThatCanAddTheSameAddressTwice()
  4. {
  5.     Person person = Isolate.Fake.Instance<Person>();
  6.     Address address = Isolate.Fake.Instance<Address>();
  7.     person.AddAddress(address);
  8.     Assert.That(person.Addresses.Count(), Is.EqualTo(1));
  9.     Assert.Throws<InvalidOperationException>(() => person.AddAddress(address));
  10. }

nUnit bombs saying that at line 8 the expected result is supposed to be 1 but in reality is 0. Why? This happens because TypeMock has created a full mockup proxy of the person object so also the methods AddAddress and RemoveAddress are mocks and they do not point to the real code we have implemented …

Control the creation
  1. [Test]
  2. [Category(“Domain.Isolated”)]
  3. public void AssertThatCanAddTheSameAddressTwice()
  4. {
  5.     Person person = Isolate.Fake.Instance<Person>(Members.CallOriginal, ConstructorWillBe.Called);
  6.     Address address = Isolate.Fake.Instance<Address>();
  7.     person.AddAddress(address);
  8.     Assert.That(person.Addresses.Count(), Is.EqualTo(1));
  9.     Assert.Throws<InvalidOperationException>(() => person.AddAddress(address));
  10. }

If we change the way TypeMock is creating the object Person, we can now say to it:

Dear TypeMock, I want that you create an instance of my object and that you call its constructor so that I can test the code I have implemented in this abstract class …

Et voila’, the test will pass! Same thing for the remove address and so on …

Now, the last test we may require is that we want to be sure that when we create a new address, the constructor is properly injecting the parent Person object so that we can keep a back-forward reference from the parent object and the collection of children.

Test injection in constructor
  1. [Test]
  2. [Category(“Domain.Isolated”)]
  3. public void AssertThatWhenCreateAnAddressTheParentPersonIsInjected()
  4. {
  5.     Person person = Isolate.Fake.Instance<Person>(Members.CallOriginal, ConstructorWillBe.Called);
  6.     Address address = Isolate.Fake.Instance<Address>();
  7.     Assert.That(person, Is.Not.Null);
  8.     Assert.That(address, Is.Not.Null);
  9.     Assert.That(address, Has.Property(“Person”).EqualTo(person));
  10. }

We run the test and kabum! It fails again. This time it fails on the address side because the Person instance TypeMock is injecting is not the same it returned to use in the previous line of code. So what can we do now?

We can manually create an Address and inject the parent Person but it sucks … or we can do this:

Customize constructor
  1. [Test]
  2. [Category(“Domain.Isolated”)]
  3. public void AssertThatWhenCreateAnAddressTheParentPersonIsInjected()
  4. {
  5.     Person person = Isolate.Fake.Instance<Person>(Members.CallOriginal, ConstructorWillBe.Called);
  6.     Address address = Isolate.Fake.Instance<Address>(Members.CallOriginal, ConstructorWillBe.Called, person);
  8.     Assert.That(person, Is.Not.Null);
  9.     Assert.That(address, Is.Not.Null);
  10.     Assert.That(address, Has.Property(“Person”).EqualTo(person));
  11. }


We simply inject the person value we want to use (the one created by TypeMock) because this is what it is going to happen with live code. What we care here is to be sure that inside the Address class constructor, the Person parameter is passed to the read-only property Person of the Address class, nothing more, nothing less!


As you can see, TypeMock is pretty cool and it allows you to control the way we can create and fake objects. Even if we use proxies we can still ask to TypeMock to create a real mock that reflect our code so that we can still test the business logic included in our objects without the need of creating complex objects manually.

If you want to read more about this topic I kindly suggest you this:

In the next tutorial we will see how to customize the methods and other behaviors of an object and I will also publish the first part of the quiz that will allow you to win almost 1,000 USD value of TypeMock license!

Stay tuned

TypeMock tutorial #01. Startup.

The best way to learn a tool is to try it, test it and then finally use it over your code. Of course if the tool provides also a great community support and a great documentation the task will be easier.

Some weeks ago we started to adopt a wonderful tool to create mockups and other TDD fancy stuff, the tool is TypeMock.

The idea I got is to create a series of tutorials about TypeMock and provide to you a piece of a code to download a full license of this tool. At the end of the series (probably 1 month) you will be able to enable your 10 days trial into a full working license. I will create a sort of bid and from all my readers that will contact me to get the license I will come up with one or two free licenses.

Guys, consider that one license of TypeMock is 800 $ !!

Setup and Installation

In order to start right away with TypeMock you need to download the latest version of the tool (at this time they have the version 6.0.10) but be careful because they upload new versions often. The product you need to download for .NET is Isolator.NET. They also provide additional tools that we will analyze during this series, like:

  • TestDriven.NET, an integrated test runner for Visual Studio
  • Isolator for Sharepoint
  • Isolator for ASP.NET and ASP.NET MVC
  • TeamMate, a useful tool to monitor your TDD approach
  • Isolator ++, the same version but for C++
  • TestLint, a nice tool that will help you to develop your TDD skill

and more.

After you have downloaded the setup (7 Mb) you will have to follow a very straightforward setup wizard with only two options available; use the advanced option and install everything including the samples for .NET.

That’s it, you are now ready to go!

File Location

TypeMock is installed on your C:\ drive and depending on where you choose to install it, you should have a folder called TypeMock/Isolator/6.0 on your Program Files directory. Inside this folder you can find all the assemblies available from TypeMock.

You do not need to use them directly as TypeMock is also installed on your GAC folder but if you plan to work with C.I. (Continuous Integration) you may probably need to add a reference to these files instead of pointing directly to the GAC, depending on what type of build server you are working with … Winking smile

Inside the folder Examples you will find a set of useful examples to start to learn TypeMock quickly but do not worry as I will go through all these examples in this series.

If you want to make your experience with TypeMock easier and smoother, I kindly suggest you to download and install also TestDriven.NET or Resharper with Gallio. I personally use and love Resharper so you will find in this series all the reference examples pointing to the Resharper UI inside Visual Studio. The choice is up to you but I personally believe R# is the best tool so far for Visual Studio (IMHO)

Visual Studio integration

After the installation you can open Visual Studio and this is the surprise you will find in the IDE:

Screen shot 2011-06-13 at 11.56.00 PM You will find a new menu on Visual Studio called TypeMock; in this menu you can setup the license, the profiler to use with TypeMock and few other options for a better Visual Studio experience.

There aren’t a lot of other ways to easily configure TypeMock but we will see together how you can tackle each of the common tasks you may encounter while working with TypeMock.

From this menu you have also the easy option of enabling/disabling TypeMock at anytime so that you can or cannot work with it without the need to restarting Visual Studio every time (like you have to do with other plugins of Visual Studio).

The Demo Project

I have created a very small project for this series of tutorials to show you how you can test every single layer of a .NET application using TypeMock to separate the dependencies. The structure of the demo project is in the following way:

Screen shot 2011-06-19 at 4.26.58 PM

The project is composed by 4 different layers:

  1. TypeMockDemo: the project that contains the Domain Model of the tutorial
  2. TypeMockDemo.DataLayer: a data layer built around NHibernate 3.2
  3. TypeMockDemo.ServiceLayer: the service layer used to write the business logic around the domain and the data layer
  4. TypeMockDemo.UserInterface: an application developed using WPF 4.



For each project there is a corresponding “fixtures” project that includes all the fixtures related to the project. With fixture I mean “test” … Winking smile

Tutorials and resources

Before starting to follow this series I kindly suggest you to have a look at the TypeMock web site learning content, so that you will follow better my tutorials. As you know, I do not usually go too deep into a specific topic, so if you need to learn also what TDD is, I kindly suggest you to read also the following tutorials about TDD and testing in general.

TypeMock learning content:

TDD learning content:


So stay tuned and I’ll see you next Friday for the next part of this series.