The way WCF proxies are designed is to live until shi* happens.

Let's assume that we have a CalcualtorService with one method named Divide(int a, int b). Sasha, a cool programmer-dude, trying to produce some usefull software writes:

public MyCalcualtorForm : Form {

   private CalculatorProxy _calc = new CalculatorProxy();

   Calc_Click(...) {
      _calc.Divide(firstNumber, secondNumber);
   }
}

What is the first error you can think of that could happen? Yep, DivideByZeroException.
Once the proxy gets an exception, it enters into a "Faulted" state which makes the proxy unusable(=you cannot use it again).
The quickest solution is to work "by the book" and create a new instance each and every time we need to call the service:

Calc_Click(...) {
   using (CalculatorProxy calc = new CalculatorProxy())
      calc.Divide(firstNumber, secondNumber);
}

But what's bad in this solution?

1. Performance - you pay (not a lot but neither little) for each creation of the proxy. Sure, it will probably not be your bottleneck, but heck, why is it useful? Most of the time the proxy will not throw an exception and yet we need to create it every time just to avoid the faulted state scenario. 
2. Design - If we declare this exception BY CONTRACT, I would expect that the proxy will still be usable afterwards. Do we really want to return Enum\int\string as status instead of throwing exception just because of poor design?
3. TDD - you know that I'm in love with it. Now imagine Dependency Injection. Component A recieve ICalculatorProxy and use it to... calculate something. Working "by the book" is no good as we want to recieve an instance of the proxy from the outside in order to mock it. Right, so we inject a proxy from the outside (got to love Windsor) and life is pretty sweeet. Darn! Wait! one poor (even by design) exception and our proxy goes dead. Very un-TDDish of Microsoft.

I had to come with a solution as no one will take TDD away from me. I present to you ProtectedProxy: this little IL-code-at-the-end-of-the-day will able you to recover from faulted state by creating a new proxy on each exception thus making your proxy... useable (couldn't think about a better word to describe it). Think about a situation where your proxy is trying to call the service but the service is down; In Semingo, we decided that we want to keep trying until the service is up. Via ProtectedProxy, you can determine how many times do you want to recover and when you should finally kill the proxy. Oh yea, ProtectedProxy uses Windsor in order to create new proxies if needed and logging messages to log4net. Good stuff.

In the example above, all Sasha had to do was to:
1). Initialize the _calc field by:
        ProtectedProxy<ICalculatorProxy> _calc = new ProtectedProxy<ICalculatorProxy>(new CalculatorProxy());
2). call _calc via:
        _calc.Instance.Divide(firstNumber, secondNumber);

But enough said, code please:

// Written by Oren Ellenbogen (07.08.07) - trying to protect our proxies so they could recover from:
// (A) The service is not up yet, but we want to try again later.
// (B) The service throws (ANY) exception, we still want our proxy to function (bubble the exception, but still keep on working).
// Microsoft intended to use a NEW proxy per call, but for TDD this is not ideal as we would like to inject proxies from outside as mocks
// in order to simulate multiple scenarios.

#region using

using System;
using System.Reflection;
using System.ServiceModel;
using Castle.Core.Resource;
using Castle.Windsor;
using Castle.Windsor.Configuration.Interpreters;
using log4net;

#endregion

namespace Semingo.Services.Proxies.Helpers
{
   
   public interface IProxy : ICommunicationObject { 
      bool Ping();
   }

Hours of joy...

Almost forgot, on the next post - "How to TDD WCF code" - stay tuned...

In my previous post, "How to mock static class or static member for testing", Eli replied that mocking static data can be easily achieved via TypeMock with no extra work around it. Although Eli raised a valid point while TypeMock is a very strong framework that you should check out, I still believe that designing for testability overcomes the basic need for testing your code. Trying to use some sort of powerful Profiler-based framework in order to mock your "wires" is a great thing, but I would use it only if refactoring the code will take too much time or effort that will beat the value of performing the change.

I would like to make my teammates think toward testability while designing the API.

Breaking your code so it will be easily tested will make things a little bit more complex in terms of dependency injection (object A will need to get IB in its constructor in order to work rather then creating new instance of B inside of it), but the allegedly weakness of breaking your code, making you stray from the pure OOP you've learned in "OOP for dummies" courses at the university, is the exact strength I see in TDD. Designing the code by writing use-cases, playing with the API, breaking classes for Single Responsibility and constant refactoring wins the purpose of testing solely or pure OO code. Don't get me wrong, pure OO is nice on the surface, but don't get fooled by it. You write code to create successful software, not successful practice of old paradigms.

TDD constantly demands to re-design the system and refactor it to fit the needs the system invocate, having the tests will back you up in the path. This way you can follow the guidelines of a sane development process:
1). Design the general architecture (the big picture)
2). Agree on interfaces between components
3). Unit-test user stories (use-cases) and drill down into the design by each test.
4). Build Integration tests to connect between components.

and so on...

Now, if you want to refactor existing code or add new behaviors, it's simple:
1). Refactor the code.
2). See that everything compiles.
3). Run unit & integrations tests.
4). If all is good - check-in your source.

Claiming that TDD-OO is not pure OO is fine by me. I would prefer TDD-OO based code on pure OO any day.

One of the problems with static members or static classes is that you can't mock them for proper unit-testing. Instead of taking this fact for granted, let's demonstrate it. Assume that we have the following classes (please note, this is just an example, not production code or anything that I'll be proud of later on):

public class CsvDataExtractor
{
    private string _documentPath;

    public CsvDataExtractor(string documentPath)
    {
        _documentPath = document;
    }

    public string ExtractFullName()
    {
        string content = CsvDocumentReader.GetContent(_documentPath);
        string fullName = // extract full name logic
        return fullName;
    }
}


[Test]
public void ExtractFullName_DocumentHasFirstNameAndLastNameOnly()
{
    CsvDataExtractor extractor = new CsvDataExtractor("c:\test.csv");
    
    string result = extractor.ExtractFullName();
    
    Assert.AreEqual("ellenbogen", result);
}

In my last post, I wrote about Implementing a simple multi-threaded TasksQueue. This post will concentrate in how to test for Thread Safety of the queue. Reminder: our queue is used by multiple consumers which means that I must make sure that before each Enqueue\Dequeue\Count, a lock will be obtained on the queue. Imagine that I have 1 item in the queue and 2 consumers trying to dequeue this item at the same time from different threads: The first dequeue will work just fine but the second will throw an exception (dequeue from an empty queue). We're actually trying to make sure that this queue works as expected in multi-threaded environment. So far about our goal.

So how can we test it?
Testing for the queue's thread safety through testing of TasksQueue, the way it's written now, can be quite hard and misleading. The ConsumeTask method calls dequeue inside a lock but what if we had a thread-safety-related-bug there? do we test only that the dequeue works as expected? not really. ConsumeTask (1) dequeue an item and then (2) "consume it". We're actually testing 2 behaviors\logics - this way, it's really hard to test only for the queue's thread safety. We should always test a single method for a specific behavior and eliminate dependencies. Only when we cover our basis, we can check for integration between multiple components (the underlying queue and the TasksQueue).

One way of allegedly achieving this goal is to create a decorator around the queue, let's call it SafeQueue, which will encapsulate a queue and wrap it with thread-safe forwarding of the calls (it will lock some inner object and call the original queue). The SafeQueue could be tested then by its own and used by our TasksQueue. This will "enable" us to remove the locking in the TasksQueue and use Set\WaitOne instead of Pulse\Wait in order to notify our consumers on arrival of a new task: 

while (_safeQueue.Count == 0)
   Monitor.WaitOne();

// NOTICE: by the time we get here, someone could have pulled the last item from the queue on another thread!
string item = _safeQueue.Dequeue();

WATCH OUT: This is a deadly solution that will make our TasksQueue break in a multi-threaded environment. Just like that, our code is not thread-safe anymore although we're using a SafeQueue that expose (atomic) thread-safe methods\properties. This is exactly why instance state should not be thread-safe by default (more details at Joe Duffy's post).

The locking of the queue should remain in our TasksQueue, but we should separate the dequeue part from the handling part and check each one by its own. We'll check the dequeue part for thread-safety(assuming that the underlying queue was tested by itself) and the handling part for pure logic. We can now test that for X calls for enqueue we get the same X calls for dequeue.

Here is the refactored code:

private void ConsumeTask()
{
   while (true)
   {
      string task = WaitForTask();

      if (task == null) return; // This signals our exit

      try
      {
         // work on the task
      }
      catch (Exception err)
      {
        // log err & eat the exception, we still want to resume consuming other tasks.
      }
   }
}

protected virtual string WaitForTask()
{
   lock (_locker)
   {
      // if no tasks available, wait up till we'll get something.
      while (_queue.Count == 0)
         Monitor.Wait(_locker);

      // try to put it outside of the lock statement and run the test(bellow)
      return _queue.Dequeue(); 
   }
}

Now we can create a simple test for the thread safety by overriding both of the enqueue\dequeue methods:

internal class TestableTasksQueue : TasksQueue
{
   private static int _dequeueCount = 0;
   private static int _enqueueCount = 0;

   public TestableTasksQueue(int workerCount) : base(workerCount) {}

   protected override string WaitForTask()
   {
      string item = base.WaitForTask();
      Interlocked.Increment(ref _dequeueCount);
      return item;
   }

   public override void EnqueueTask(string task)
   {
      base.EnqueueTask(task);
      Interlocked.Increment(ref _enqueueCount);
   }

   public static int DequeueCount
   {
      get { return _dequeueCount; }
   }

   public static int EnqueueCount
   {
      get { return _enqueueCount; }
   }
}

The tricky part here is the test itself. Because of subtle multi-threading issues, we can't actually know when 2 (or more) threads will try to dequeue on the same time, so we have to run this test enough times in order to detect bugs. Here is a little sample:

[TestFixture]
public class TasksQueueTests
{
   [Test]
   public void Counting_DequeueAndEnqueueCountsShouldBeEqual()
   {
      for (int j = 0; j < 1000; j++)
      {
         using (TestableTasksQueue queue = new TestableTasksQueue(5))
         {
            for (int i = 0; i < 100; i++)
               queue.EnqueueTask("test" + i);
         }

         Assert.AreEqual(TestableTasksQueue.DequeueCount, TestableTasksQueue.EnqueueCount);
      }
   }
}

Well, it's not that elegant, I know, but thread-safety is hard to test.
I would love to hear some suggestion from you regarding this issue.

Damn, it was so much fun to play a little with TDD and abstract the lousy API given by Microsoft to register client-side script. I'll write about the process and design changes I've made due to testability reasons. TDD is a great design tool, it's amazing to witness the "before" and "after" of your code, all because of the requirements to test things separately.

Here are a few API samples, taken from the Demo project (you can play with it and see the results):

Keep in mind that I'm only supplying a different API (abstraction) of Microsoft's implementation. In order to accomplish that, I'm using Windsor to wire the ClientSideExtender with the new ajaxian ScriptManager(supports UpdatePanel), which will actually be responsible to register the script under the hood. You can look at the web.config (under the <castle> element) for more details.

Source:
Lnbogen.Web.UI.zip (253.56 KB)

Phil Haack gives an excellent example of how to test a registration to event while implementing MVP pattern (via Rhino Mocks). If you did not read it yet, take a pause for 2 minutes and give it a look; It is worth it, I promise.

The only thing that bothers me in the example is that the need to assert the triggering of the event kind of spoiled the code. I think that in those scenarios, it's much better to use some sort of Stub and override the class under test in order to keep the it cleaner. So instead of having this code:

public class Presenter
{
   IView view;
   public Presenter(IView view)
   {
      this.view = view;
      this.view.Load += new EventHandler(view_Load);
   }

   public bool EventLoaded
   {
      get { return this.eventLoaded; }
      set { this.eventLoaded = value; }
   }

   bool eventLoaded;

   void view_Load(object sender, EventArgs e)
   {
      this.eventLoaded = true;
   }
}

I would have created something like this:

public class Presenter
{
   IView view;
   public Presenter(IView view)
   {
      this.view = view;
      this.view.Load += new EventHandler(view_Load);
   }

   protected virtual void view_Load(object sender, EventArgs e)
   {
       // production code here
   }
}


// This will go in the PresenterTests class
public class TestablePresenter : Presenter
{
   public bool WasEventLoaded = false;
   protected override void view_Load(object sender, EventArgs e)
   {
       WasEventLoaded = true;
   }
}

Now we can create an instance of TestablePresenter and Assert the WasEventLoaded field.
My guess is that Phil actually did something like this in his project and merely wanted to show an example, but I still thought it was important enough to demonstrate this separation as I firmly believe we must make sure that our need for tests will not actually hurt the design.

Source Code:

RhinoMocksExample.zip (94.18 KB)

You will need to download and install Nunit 2.2.8 and RhinoMocks(for .Net 2.0) in order to run the tests.

Background:

Not as usual, we'll start with the code and continue with it's UnitTests.
We have a single, simple class named MailService. This class contains one method named MailText(string textToMail, params MailInfo[] mailList) that looks like this:

public class MailService
{
   private IMailValidator m_mailValidator;
   public IMailValidator MailValidator // setter, getter

   public void MailText(string textToMail, params MailInfo[] mailList)
   {
      foreach (MailInfo mail in mailList) { //I know I can collect addresses...
         ValidationResult validationResult = this.MailValidator.Validate(mail);

         if (!validationResult.IsValid)
            throw new ArgumentException("Invalid mail: " + validationResult.ValidationMessage, "mail");

         // Send the email somehow...
      }
   }
}

And here is the IMailValidator, MailInfo and ValidationResult:

public class MailInfo {
   public string Address; //not best practice
   public MailInfo(string address) { this.Address = address; }
}

public class ValidationResult {
   public bool IsValid; //not best practice
   public string ValidationMessage; //not best practice

   public ValidationResult() { IsValid = true; ValidationMessage = string.Empty; }

   public ValidationResult(bool isValid, string message) {
      IsValid = isValid;
      ValidationMessage = message;
   }
}

public interface IMailValidator {
   ValidationResult Validate(MailInfo mail);
}

That is pretty straightforward I hope.


Testing inner behavior:

MailService.MailText has one dependency to IMailValidator. One way of testing our MailService.MailText method is via manual stub implementation of IMailValidator. Let's examine the tests and then look at the manual stub I've created.

1). Manual stub based testing:

[TestFixture]
public class MailServiceTests
{
   [Test]
   public void MailText_OneValidEmail_MethodWorks()
   {
      MailService service = new MailService();
      MailInfo mail1 = new MailInfo("valid@mercury.com");

      service.MailValidator = new StubMailValidator();

      service.MailText("Enlarge your 'memory stick'", mail1);
   }

   [Test]
   [ExpectedException(typeof(ArgumentException))]
   public void MailText_OneValidEmailAndOneInvalidEmail_ThrowException()
   {
      MailService service = new MailService();
      MailInfo validMail = new MailInfo("valid@mercury.com");
      MailInfo invalidMail = new MailInfo("invalid.com");

      service.MailValidator = new StubMailValidator();

      service.MailText("Enlarge your 'memory stick'", validMail, invalidMail);
   }
}

And here is the simple StubMailValidator in one of it's versions: (This stub was developed after the first test(MailText_OneValidEmail_MethodWorks) was written)

public class StubMailValidator : IMailValidator
{
   public ValidationResult Validate(MailInfo mail)
   {
      ValidationResult res = new ValidationResult(); //default: valid.
      if (mail.Address.IndexOf(".com") == -1) {
         res.IsValid = false;
         res.ValidationMessage = "The email address must end with .com";
      }

      return res;
   }
}

NOTICE: Manual stubs with inner logic can be devastating !

As you may or may not notice, this stub has a bug in it. Just look at the second test on the "invalid.com" MailInfo. This is an invalid email address and yet, our stub will say that it's valid and fail our second test. This is extremely dangerous! It is one of the things that makes people afraid from Unit Testing. When your stub need to switch his response according to a given parameter(s) based on some logic, you better switch your manual stub with dynamic\generated stub. You don't want any test-related logic outside of your test method. Let's look at mocked stub testing.

2). Mock stub based testing:

I'm using Oren Eini's (aka Ayende) RhinoMocks for simulating "controlled" implementation of IMailValidator. That means that you are creating some dynamic implementation of IMailValidtor and you are telling it how to act when the tested method calls it.

Let's look at our first test:

[Test]
public void MailText_OneValidEmail_MethodWorks()
{
   MailInfo validMail = new MailInfo("valid@mercury.com");
   ValidationResult validValidationResult = ValidationResult(true, string.Empty);

   // ------ (1) -------
   MockRepository mocks = new MockRepository();
   IMailValidator validator = (IMailValidator)mocks.CreateMock<IMailValidator>();
   Expect.Call(validator.Validate(validMail)).Return(validValidationResult);
   // ------------------

   service.MailValidator = validator;

   mocks.ReplayAll(); // Make sure the mock object is ready to "respond"

   service.MailText("Enlarge your 'memory stick'", validMail);

   mocks.VerifyAll(); // Make sure everything was called correctly.
}

(1) - This is the important stuff. I'm asking the MockRepository to create a new Mock from IMailValidtor type that our MailService expect. The line in bold tells this story: "listen dear mocked validator, if someone calls your Validate method with the parameter validMail - please send him back validValidationResult object". If we know that our validator will be called twice - we'll have two lines with Expect.Call as needed.

One of our main purpose in UnitTesting is to test one method (and one method only) and see if it behaves correctly if it receive a certain data. We also want to check the stomach of the method, what happen if our tested method calls another method(dependency) that return "1" - will it still behave as expected? Via Mock object I can control the dependency object's result easily inside the test. This make it very easy to detect bugs in contrast to our manual stub that sits somewhere else, outside of our test.

Recap:

If you have a dependency to some other object and your manual stub start to contain logic, you should mock that dependency and control the returned values in the same place you write your tests via mock object.

Bonus (delegates style Interaction Based Testing):

[Test]
public void MailText_OneValidEmail_MethodWorks2()
{
   MailInfo validMail = new MailInfo("valid@mercury.com");
   ValidationResult validValidationResult = ValidationResult(true, string.Empty);

   RunMock<IMailValidator>(
      delegate(IMailValidator validator, MockRepository repository) {
         Expect.Call(validator.Validate(validMail)).Return(validValidationResult);

         service.MailValidator = validator;
         repository.ReplayAll();

         service.MailText("Enlarge your 'memory stick'", validMail);
      }
   );
}

private void RunMock<TObjectToMock>(MockedProc<TObjectToMock> func)
{
   MockRepository mocks = new MockRepository();
   TObjectToMock obj = (TObjectToMock)mocks.CreateMock<TObjectToMock>();

   func(obj, mocks);

   mocks.VerifyAll();
}

private delegate void MockedProc<TObjectToMock>(TObjectToMock mockedObject, MockRepository repository);

This (very)little beauty is getting along quite nicely. I'm going to work quite a bit on it in the following days so keep tracking...

source:

Lnbogen.SeeCompass_v0.2.zip (205.34 KB)

After sitting with Roy during our last meeting, we managed to write some neat tests and code and the SEE(Simple Expression Engine) infrastructure started to crystallized. Roy even managed to refactor the name of my infrastructure and brought a brilliant suffix - SeeCompass. SEE is like a compass that helps you navigate in the ocean of data; man, I think that the web-bully will not be happy with this phrase.

If you don't remember what is SeeCompass all about read this post.

Source:

Lnbogen.SeeCompass.zip (156.39 KB)

How to start:

1. Open the solution (I know, revolutionary).
2. Open Lnbogen.SeeCompass.Framework.Tests project.
3. Open the file FilterExpressionTests.cs under FilterExpression directory.
4. Jump to the test Build_EmptyFilter_EmptyString (remember the method name structure: MethodToTest_MethodState_ExpectedResult).
5. Move on to the next test, one at a time.

I know, it can be a little hard to grasp the "entire picture" at the moment, but the tests should give you a good pick at the future.
As always, I left one failing test which will lead to a very drastic refactoring (BetweenExpression should have more than one parameter) - this will give me an entry point to continue.

After talking about testing inner behavior inside a method, it is time to make some observations about the code and answer a lot of *why* questions. I must give credit to Shani, one of a great bunch of people I worked with during my service and a very good friend of mine. He asked me some hard questions that bother every TDD newbie or a TDD wannabee as myself (raise your hand if you're one of them.. higher!). Now I'll take my shot and reply in detail.

Question 1: Is it worth spending time on tests for simple methods ?

I've talked about "code little, think and code little" and why we need it in my last post "TDD in the eyes of a simpleminded: Part 1 - The NameResolver". One of the great comments I received was "You spent more time on the tests than on the (simple)method itself. Isn't it time consuming? You've just talked about focus on deadlines in your preface..". From my experience, the easy, 5 minutes, methods are the one you spend most the time thinking about(relatively). You keep saying to yourself "this is so easy... such a shame" and spend a full hour thinking about a various of problems that can happen and various solution to handle them: " Maybe I'll use array? no... maybe List<int>? no... Oh! Yes! I'll use an interface! I'll call it IMyCollection and make a nice method in it named "AISolveProblem(params object[] anyThing)" ". This all process take place before you even write your first line of code! It's a 5 minutes, even-a-lame-monkey-can-do-it method. You don't want to look stupid and leave "open holes" right? So you waste a great deal of time over-thinking the irrelevant. Classic.

Sure, TDD can be costly (depends on a few variables), but it makes you code along the challenges(tests) and always challenge you to come up with the simplest solution. minimum effort. It prevents you from thinking too much upfront; You don't have to think too much about avoiding potential bugs, just write test cases and make them green. Don't have red tests ? Your code is ready for production. Again, I'm not going to address the big questions like "when, how and how much?" at the moment and I'm not saying that you should TDD the entire application. I'm just stating a point here. Keep your head open for a new way of coding. That's the best I can request from you and that is what I'm doing now, during the learning process with Roy.

Question 2: Changing the class because of our tests, is that a good thing ?

I think that if the time comes and you need to change the way your class looks or behaves just because your tests become hard to write, you should lay back and smile. That means that the process of TDD just helped you design your code better. If the test was too hard to write, you must be doing some uncomfortable API (usability warning) or maybe you've put too much knowledge in one place and created a GOD(do-it-all) method\class. Having 5+ dependencies in one class should make you stop and rethink about the way you work right? testing actually makes you write the API before you actually write the implementation itself. If the early API sketching is too hard, just think about the poor programmer which will have to work with your API, about yourself (if it's hard to test it must be hard to write) and even better - the miserable programmer which will have to take over your code and maintain it later on.

Question 3: Injecting concrete implementation can lead to incorrect usages! Why do we need it?

Let me start by relaxing you - injecting concrete implementation of an interface *can* lead to serious bugs and malfunctions in your application. Let me repeat it. By providing the programmer the ability to "inject" his implementation for the class dependencies he can cause the application to die. It might even cost you your job.

Relaxed?

No? But you should be! I've just demonstrated the worst case scenario and if we'll think about it together, the world is not over and you and I still got our jobs. Programmers can make mistakes while using any API. Damn it, I've asked my boss for hiring machines but he keeps bringing people who actually use their head. You see, I don't trust the "next guy" no more than you do, but I realize that I can take care of the low-level (in Hebrew: BARZELIM) API and still provide the high-level API which will help the idiot(brighter than me) next guy a simple method for any complex scenario. We need an option to inject our dependencies as we don't want to couple our classes together.

We want the option to replace one concrete implementation with another (fake one, for example). This doesn't prevent me from developing some nice & simple API that will wrap the all thing up and inject the dependencies I want.

Question 4: Writing tests can lead to bugs in those tests? should I write tests for my test?

Sure you do! you have to test your tests, and then test those tests and than test the latter one just until you will run out of RAM, space on your HD or energy.

Writing code can lead to additional bugs to your system just as living can cause death(No research shows it does by the way). We can minimize the chance of bugs in our tests by following some simple rules:

1. The test should be obvious by it's name (I follows Roy's tip: MethodName_State_ExpectedResult).
2. A test should check one method only.
3. A test should Assert only once.
4. Writing new tests should be easy and take no more than a few lines (few != 50).

I wrote "should" and not "must" as we should eat healthy food, it's not a must (unless you eat burgers 24-7, in that case, you are a goner). You should come up with the rules that fit you and your team. You can enforce them to keep a follow a few rules just to create a standard you all(or just you, no one said we are living in a democracy) agree on.

I've attached the code I demonstrated so far to the original posts so you could play with the code a little and understand how it all connects (if code samples in my posts were not clear enough).

Requirements:

• Nunit 2.2.8
• TestDriven.Net (this is actually an extra, but give yourself a break and download this gold)
• Visual Studio .Net 2005

Code (inside the posts):

TDD in the eyes of a simpleminded: Part 1 - The NameResolver

TDD in the eyes of a simpleminded: Part 2 - Testing inner behavior

Have fun !

p.s: in every additional post I'll publish about "TDD in the eyes of a simpleminded" I will upload the code.

code:

OrenTDDWorkShop_Part2.zip (44.06 KB)

If you haven't read about the NameResolver at my previous post(TDD: Part1), now is the time as I'm going to take this class and use it later on in this post.

We are ready to take the next step and talk about "playing a doctor". Imagine this picture: you are a doctor looking for a gun's bullet in one of your patient's stomach. He was shot a few moments ago. "One bullet to the chest" the nurse inform you. It's all messy and you can't find the bullet. You need to clear the blood, move the organs, going micro-level on the details so you don't hit a vein on the way. Every mistake is a "welcome-better-place" for your patient and you don't want this on your conscience do you ?

While developing applications, we are facing a world of "playing doctors". We need to change inner behaviors in our code or others code. We want the application to live the surgery and we realize that the smallest change in a "core method" can make the application bleed all over the place without even noticing it. Every click on the keyboard raises our heart rate. But how can we check inner code inside a method? How can we get a micro-level look at the method's internals, at the stomach of our tested object ?

This is what I'm going to address at this post. But before we see solutions, let's talk about the client's requirements so we'll have something to play with.

Client's requirements v1.0:

A class named HotelReservationService is required. In it, a method named ReserveRoomForTwo that receive the couple's name in the format "[man] and [wife] [family name]". The method will reserve the room and name the room under the family's name. The method will return ReservationInformation object with the details (room, floor number & status).

• If the received couple's name is empty ("") - Throw an exception with "The couple name must be supplied".
• If the hotel don't have available rooms, the returned ReservationInformation should hold a status of "NoRoomAvailable".
• if the everything goes well, the method should return a ReservationInformation filled with the floor number, room number, reservedFor (filled with the name of the family) and status of "RoomReserved".

Simple solution, without TDD:

public class HotelReservationsService
{
   public ReservationInformation ReserveRoomForTwo(string coupleName)
   {
      // .... some checks ...

      NameResolver resolver = new NameResolver();
      string familyName = resolver.GetFamilyName(coupleName);

      HotelRepository repository = new HotelRepository();
      return repository.ReserveRoom(2, familyName); // 2 = two people
   }
}

As you can notice, we have 2 dependencies here: NameResolver and HotelRepository. We need to test ReserveRoomForTwo but how can we do it ? the results of our tests for this method are coupled with the implementation of NameResolver and HotelRepository. If they have bugs in it, it will certainly affect our tests and therefore making them *unreliable*. What's the point in writing tests if you doubt that a green(successful) result might actually be red(fail) under the surface due to an inner bug in one of the dependencies?

Keeping with my metaphor, the dependencies are the blood and organs laying around and making it harder for you to find the bullet, may it be a bug or a new feature. You need to clear(isolate) the area so things will be easier to see. You need a green light you can actually *trust*.

We'll need to use Dependency Inversion Principle(DIP) to isolate our tested class from the actual implementation of its dependencies.

Our goal:

Inject dummy object instead of the dependencies and make them "act like" everything is good\bad according to our need. Will use DIP to make it happen.

We don't want to test NameResolver nor HotelRepository. We assume that they are bugs-free. We need to test one and only one class at a time. Our goal is to test the interaction between our tested class to its dependencies.

Let's use TDD to solve the client's requirements:

Say hello to your new friend: geek, this is Stub; Stub, this is geek. Come on, don't be shy, give him a hug, he will serve you well in time. Feel nice and fuzzy ? great, now let's TDD this baby. Oh, and don't worry, if you don't understand the concept of "Stub" yet, everything will be clearer in a few moments. Just think about Stub as a dummy object.

We start with? Come on! I want to hear it from you! we'll start with a Create method!

[TestFixture]
public class HotelReservationsServiceTests
{
   [Test]
   public void Create()
   {
      HotelReservationsService service = new HotelReservationsService();
      Assert.IsNotNull(service);
   }
}

As usual, in order to compile this method we'll need to create an empty class:

public class HotelReservationsService
{
}

Let's run the test - 1 passed, 0 failed. Good.

Let's write our second test and look to our requirements:

[Test]
[ExpectedException(typeof(ArgumentException), "The couple name must be supplied")]
public void ReserveRoomForTwo_EmptyCoupleName_ThrowEmptyCoupleNameException()
{
   HotelReservationsService service = new HotelReservationsService();
   ReservationInformation info = service.ReserveRoomForTwo(string.Empty);

   // We've got nothing to assert. We expect an exception to raise.
}

This will not compile as we don't have ReserveRoomForTwo method nor ReservationInformation class. Let's write them down:

public class ReservationInformation
{
   private int m_roomNumber;
   private int m_floorNumber;
   private string m_reservedFor;
   private string m_status;

   public ReservationInformation(string reservedFor, int floorNumber, int roomNumber, string status)
   {
      ReservedFor = reservedFor;
      FloorNumber = floorNumber;
      RoomNumber = roomNumber;
      Status = status;
   }

   public string ReservedFor
   {
      ... get & set ...
   }

   public int FloorNumber
   {
      ... get & set ...
   }

   public int RoomNumber
   {
      ... get & set ...
   }

   public string Status
   {
      ... get & set ...
   }
}

Now let's add the ReserveRoomForTwo method to our HotelReservationsService:

public ReservationInformation ReserveRoomForTwo(string coupleName)
{
   throw new NotImplementedException("");
}

Compile. Run tests - 1 passed, 1 failed. Our test expect for ArgumentException with a specific message but we throw NotImplementedException. Let's fix it.

public ReservationInformation ReserveRoomForTwo(string coupleName)
{
   throw new ArgumentException("The couple name must be supplied");
}

Run tests - 2 passed, 0 failed. Good.

Time for refactoring our tests as we create the HotelReservationsService in two methods. This time, instead of creating a "FactoryMethod" named GetNewHotelReservationsServer like we did in our NameResolver tests, let's use the [Setup] attribute.

[TestFixture]
public class HotelReservationsServiceTests
{
   HotelReservationsService service;

   [SetUp]
   public void SetupTest()
   {
      service = new HotelReservationsService();
   }

   [Test]
   public void Create()
   {
      Assert.IsNotNull(service);
   }

   [Test]
   [ExpectedException(typeof(ArgumentException), "The couple name must be supplied")]
   public void ReserveRoomForTwo_EmptyCoupleName_ThrowEmptyCoupleNameException()
   {
      ReservationInformation info = service.ReserveRoomForTwo(string.Empty);
      // We've got nothing to assert. We expect an exception to raise.
   }
}

Let's continue to check our requirements: We want to represent a case where the provided couple's name is good but the hotel is full.

[Test]
public void ReserveRoomForTwo_HotelIsFull_ReservationInformationWithStatusNoRoomAvailable()
{
   // We create a dummy repository and set the values we want it to return.
   FakeHotelRepository repository = new FakeHotelRepository();
   repository.StatusToReturn = "NoRoomAvailable";
   service.SetRepository(repository); // Important! set the fake repository in the service.

   string goodCoupleName = "man and woman FamilyName";
   ReservationInformation info = service.ReserveRoomForTwo(goodCoupleName);

   Assert.AreEqual("NoRoomAvailable", info.Status);
}

Run tests - 2 passed, 1 failed(our last one).

We get an exception here which is obvious (we hard-coded "throw new ArgumentException...") instead of a status "NoRoomAvailable". Notice that we are create a FakeHotelRepository and injecting it to our tested class. The purpose is to create a repository which will always return "NoRoomAvailable". We want to test the *interaction* between our ReserveRoomForTwo method in our tested object to the repository. This can look bizarre but let's remember that we want to test only our ReserveRoomForTwo method and not the repository class.

Let's make our test green. minimum effort.

We need some sort of HotelRepository in order to know if the hotel is full. At the moment, we don't need the NameResolver as we are looking for the status only. Let's define an interface named IHotelRepository.

public interface IHotelRepository
{
   ReservationInformation ReserveRoom(int capacity, string familyName);
}

This time we need to build the "basics" so the minimum effort will be a little more than we use to, but that's OK as we'll do it only once. Let's add this code to our HotelReservationsService class:

private IHotelRepository m_repository;

private IHotelRepository Repostiory
{
   get 
   { 
      if (m_repository == null)
         throw new ArgumentNullException("Repostiory", "Repository must be set before being used");

      return m_repository; 
   }
   set { m_repository = value;}
   }
}

public void SetRepository(IHotelRepository repository)
{
   Repostiory = repository;
}

Now we can use the repository in our ReserveRoomForTwo method:

public ReservationInformation ReserveRoomForTwo(string coupleName)
{
   if (coupleName == string.Empty)
      throw new ArgumentException("The couple name must be supplied");
   else
   {
      ReservationInformation info = this.Repostiory.ReserveRoom(2, coupleName);
      return info; // just so we'll remember that we return ReservationInformation.
   }
}

We call the repository and ask it to save a room for the received couple. All we left with is to create the FakeHotelRepository object:

This class will sit in the tests project and will be used for testing only. Notice that we can manipulate the data we want to return from this repository. Remember: we want to test the interaction between the classes. We assume that the repository in production was tested and will be able to "know" if the hotel is really full or not. We make a fake one so we can control the internal behavior. We are playing doctors: Assuming that the repository is OK, will our class still behave as we expect ?

We can play with the repository and look at the results we get. Will do the same with the NameResolver later on.

Run the tests - 3 passed, 0 failed. So far, requirements 1 and 2 are set.

What is Stub then ?

stub is an object that helps you test another object. You never ever Assert the stub itself.
You use it only as an helper while you're looking to test another object.

In our example, the FakeHotelRepository is a classic stub. We use it to assert another object - ReservationInformation.

Let's take a pause here as this post cover a lot of material and code. The next post will answer the third requirement and I'll present additional solution for the problems we encounter here.

If you didn't read the preface yet, I strongly recommend you to invest good 5 minutes for it now; I'll wait...

Code:

OrenTDDWorkShop.zip (37.09 KB)

the NameResolver:

This class should have a method named GetFamilyName that gets a string as parameter and return the last name of a person.

The client defines these requirements:

• If the sent string is empty (""), the method should return "None".
• The string can contain only one word - in this case, return that word.
• The string can contain first name and last name separated by space between them. The method should return the last name (obviously).

Simple enough right ?

Let's TDD this thing. We start with a "Create" test:

[TestFixture]
public class NameResolverTests
{
   [Test]
   public void Create()
   {
      NameResolver c = new NameResolver();
      Assert.IsNotNull(c);
   }
}

This code doesn't compile as we don't have NameResolver class yet. This test will check that we have an empty constructor for NameResolver and that we can actually initialize it. So let's write the required code:

public class NameResolver
{

}

Run the test. It works. It's time to test our GetFamilyName method. Let's see if the first requirement works:

[Test]
public void GetFamilyName_EmptyString_ReturnTheWordNone()
{
   NameResolver c = new NameResolver();

   string actualResult = c.GetFamilyName(string.Empty);
   Assert.AreEqual("None", actualResult);
}

Notice the structure of the method:

MethodName_State_ExpectedResult

This will not compile as we don't have the method GetFamilyName, so we'll make the minimum effort to make it compile.

public class NameResolver
{
   public string GetFamilyName(string fullName)
   {
      throw new NotImplementedException("");
   }
}

Now it compiles. Nice. Let's run the test. 1 passed, 1 failed(our last test).

Let's refactor the method so it will pass, remember, minimum effort.

public string GetFamilyName(string fullName)
{
   return "None";
}

I know, it doesn't make sense at first. The trick here is "baby-steps". You will add new code or refactor existing one only if you have a test that prove you *need* to do so. Our tests pass without problems so we don't have to modify our GetFamilyName. It works as expected so far!

Before we are running along and writing another test that will fail let's make some refactoring. We can do it with peace as we have tests to run after we change our code. In my tests you can see a line that repeat itself which is "NameResolver c = new NameResolver();". We don't like initializing new objects in the tests method as this initialization can get complex later on and we don't want to change X test methods. Refactoring:

[Test]
public void Create()
{
   NameResolver c = GetNewNameResolver();
   Assert.IsNotNull(c);
}

[Test]
public void GetFamilyName_EmptyString_ReturnTheWordNone()
{
   NameResolver c = GetNewNameResolver();

   string actualResult = c.GetFamilyName(string.Empty);
   Assert.AreEqual("None", actualResult);
}

private NameResolver GetNewNameResolver()
{
   return new NameResolver();
}

Compile - Good. Run tests - Good. That was simple.

Let's carry on and prove ourself that GetFamilyName is not good:

[Test]
public void GetFamilyName_OneWordOnly_ReturnThatWord()
{
   NameResolver c = GetNewNameResolver();

   string actualResult = c.GetFamilyName("test");
   Assert.AreEqual("test", actualResult);
}

Perfect, run the test - 2 passed, 1 failed (our last one)

This is quite obvious, we return None no matter what. Let's fix it. remember, minimum effort.

public string GetFamilyName(string fullName)
{
   if (fullName == string.Empty)
      return "None";

   return fullName;
}

Run tests - Good! Now that the tests were OK, we can refactor (we have the tests as our backup - to see that we didn't introduce new bugs). You can see that the lines of GetFamlyName("...") and the Assert repeat itself. Let's extract this into a private helper method and use it:

[TestFixture]
public class NameResolverTests
{
   [Test]
   public void Create()
   {
      NameResolver c = GetNewNameResolver();
      Assert.IsNotNull(c);
   }

   [Test]
   public void GetFamilyName_EmptyString_ReturnTheWordNone()
   {
      NameResolver c = GetNewNameResolver();
      VerifyGetFamilyName(c, string.Empty, "None");
   }

   [Test]
   public void GetFamilyName_OneWordOnly_ReturnThatWord()
   {
      NameResolver c = GetNewNameResolver();
      VerifyGetFamilyName(c, "test", "test");
   }
   
   private void VerifyGetFamilyName(
      NameResolver nameResolver, 
      string fullNameToCheck, 
      string expectedResult)
   {
      string actualResult = nameResolver.GetFamilyName(fullNameToCheck);
      Assert.AreEqual(expectedResult, actualResult);
   }

   private NameResolver GetNewNameResolver()
   {
      return new NameResolver();
   }
}

VerifyGetFamilyName will help us to write smaller test. We want the option to write a new test with only a couple of lines. Adding new tests should be fun.

Let's move on.

Now we don't have bugs anymore right? we do ?
prove it!

Here you go:

[Test]
public void GetFamilyName_TwoWords_ReturnLastWord()
{
   NameResolver c = GetNewNameResolver();
   VerifyGetFamilyName(c, "one two", "two");
}

Run test - 3 passed, 1 failed (our last one).
It makes sense, we don't check for space character yet so Let's fix it with minimum effort (remember?).

public string GetFamilyName(string fullName)
{
   if (fullName == string.Empty)
      return "None";
   else if (fullName.IndexOf(" ") == -1) // no spaces
      return fullName;
   else
   {
      string[] words = fullName.Split(' ');
      return words[1];
   }
}

Run tests - Good !

Hold on, you think you're done but you're not. The client adds another requirement (things change, you know):

• the string can contain 3 words - first name, middle name and last name; Separated by space, of course. Return the last name (obvious).

We have a bug! How do I know? Here you go:

[Test]
public void GetFamilyName_ThreeWords_ReturnLastWord()
{
   NameResolver c = GetNewNameResolver();
   VerifyGetFamilyName(c, "one two three", "three");
}

Run tests -  4 passed, 1 failed(our last one). Let's fix the method so our last test will work. minimum effort.

public string GetFamilyName(string fullName)
{
   if (fullName == string.Empty)
      return "None";
   else if (fullName.IndexOf(" ") == -1) // no spaces
      return fullName;
   else
   {
      string[] words = fullName.Split(' ');
      return words[2];
   }
}

Run tests - 4 passed, 1 failed (GetFamilyName_TwoWords_ReturnLastWord()). Oops! our last test passed but I screwed up our previous test (to two words scenario - "one two"). This is a great thing with TDD, you cover your ass with tests! Let's refactor:

public string GetFamilyName(string fullName)
{
   if (fullName == string.Empty)
      return "None";
   else if (fullName.IndexOf(" ") == -1) // no spaces
      return fullName;
   else
   {
      string[] words = fullName.Split(' ');
      return words[words.Length-1];
   }
}

Run tests - 5 passed, 0 failed! Good!

Conclusions:

We want to work with ~100% code coverage. That means that every piece of code in GetFamilyName method is accounted for. I don't add new features to this method until I have a test that shows it is required. In addition, look at our GetFamilyName method, the code is so simple you want to cry with joy. Instead of thinking about all the possibilities to screw this method up at the beginning, write your "bugs" and see if the method can handle it. In addition, let's say that the client request another feature ("I want to allow sending names in Hebrew and names in English. The GetFamilyName should be able to handle them both". You can change whatever you need (but with minimum effort) and you've got the tests to see that everything is still ticking as expected. Refactoring is something you can do here with a smile on your face. You don't have to be afraid changing the code. The well known sentence "But what if I'll create 5 other bugs?!" is no longer valid. You've got the tests to tell you "You're OK!".

Good tests = peace of mind.

I sat down for about 15 minutes before I could even write this sentence.

You see, as human beings, we (usually) tend to think too much before we speak.
As programmers, we (usually) tend to think too much before we write our first line of code.
"But what if the programmer will send null?"
"What if the programmer will send string when I expect int? should I throw an exception?"
"Should I return int or maybe void will do?"
"Should I implement the feature in this class? maybe I should use some external object and implement it there?"
"Should I inherit from this class or encapsulate it?"

We tend to over-think stuff. That's the way we are wired.

Tell me if you can relate to this monologue:
" I'm putting a lot of effort in finding solutions to many problems before they appear. These effort makes me tired so a few "end-cases" still slips me by; This, of course, only makes me think more before I write my code. Little, not-more-than-1-day-max missions turn into "Projects". The frustration when something breaks for unknown reason is sky-high as I spent 1-2 days just to think about how to avoid these bugs! I simply don't have enough time. I'm working like hell but the day is just too short and I've got too many tasks to complete. "

I remember sitting with my last team leader, Pasha, in the office one evening(~3 years ago), after spending 12 hours in refactoring something that never actually worked; His words were: " Oren, you fell in love with your code. You're spending way too much time on things that... are not really important at the moment.... If you keep it up this way, you'll never finish your task. "
I remember my response, his words were like a knife in my heart: " Hey! I put my guts in this code, I've stayed the all week for more than 14 hours per day! I even sat at home during the weekend and worked on this task just to keep up with the deadline! you can't tell me that this is not important! Someone can use this some day! And the design is so extendable! "Not really important..." (bad, bad, dirty thoughts) ".

He was right. I couldn't make the deadline. It was a battle I couldn't win; I had to much work and almost no time at this point.

I remember that day like it was a few hours ago. I couldn't sleep the all night. I kept running scenarios in my head and analyzing his words. I thought about the way I worked until that point, about the times I managed to complete my tasks in time and those times I worked extra hours and still miss my deadlines. I could really see what he meant. I wasn't able to think in small tasks. I connected every little piece of code with 1000 other usages "that could be used someday". I thought that I could make it all work at once. I thought that I can prevent bugs from happening. The reality proved me otherwise.

I knew that I can get better, so I set my mind on "think less, do more". I needed some basic rules to contain my need to over-think, so I use these simple rules to make my life easier:

• I refactor only when I see a tangible reason (2 places with the same code).
• I think in small "Contexts" (=tasks). No context should be bigger than 1-1.5 days of work.
• I'm trying to WIN *small* battles.
• I write some API usages, test that API with my programmers (to see if it's comfortable enough) and only than starting to code it.
• I participate others when things get a little more complicated than they should be.
• I write my milestones on my white-board so I could look at them during the day.

This is the mantra behind TDD.
TDD is about letting things go. To Work in small tasks and most importantly:

Let the *code* prove you wrong, not your thoughts or fears.

I don't have a bug until I can write a test that proves me otheriwse.
With this said, we can now start practicing TDD. Let's write NameResolver class.

* As this post turned to be quite long, you can see the example here.

clarification: if it wasn't obvious, the simpleminded is yours truly.

I'm having 1-on-1 coaching with Roy Osherove on TDD coming up in the following 2-3 weeks. My goal is to practice real TDD work process to determine if our department can benefit from this developing methodology (or as a design tool).

I've read a big bunch of articles and blogs (Jeremy D. Miller, Sam Gentile, Scott Bellware, Roy Osherove and others) about TDD and even practiced it for a bit during the last two years, but to be sincere, it wasn't a real Test Driven Development. I stopped TDD-ing in the middle and moved back to write-with-haste, switched to TDD and so forth. I was lazy and I had no one to guide me through. I had to "guess" the right process and to read a big set of articles to see if I'm on the right track. I was lacking of some good feedback.

This 1-on-1 with Roy should give me a clear insight about the process and immediate feedback. If the process will prove itself, we'll arrange a 3 days course for my department and try to fit TDD to our development process (where and how I'm still not sure, but I've got the feeling that I'll be smarter in a few weeks).

What is SEE Infrastructure all about ?

SEE stand for: Simple Expression Engine which I've wrote about before.

I came up with SEE as I wanted to SEE what sort of filter the GUI requests from our Data Services.

I'll give you an example for a client's request and a solution based on our old infrastructure and how SEE changed the picture.

Example:

Let's imagine we have a screen with one GridView. Our goal is to show all the (1) active orders (2) from today with (3) price bigger than 1000 NIS. It should be easy as counting 1,2,3 right ?

-- OLD --

With our old infrastructure the code will look something like this:

(1) Orders.aspx:

OrdersFilter filter = new OrdersFilter();
filter.IsActive = true;
filter.Date = DateTime.Today;
filter.Price = 1000;

EntityCollection<Order> orders = OrdersService.Instance.Get(filter);
// ... bind orders to our GridView ...

(2) OrdersDal.cs:

in our Data Access Object for the Orders entity, we're required to override a method which builds the dynamic SQL based on the given filter:

if (this.Filter.IsActive != null)
{
   query.Append(" AND Orders.IsActive = @IsActive");
   paramaters.Add(DbServices.CreateParameter("IsActive", SqlDbType.Bit, this.Filter.IsActive));
}

if (this.Filter.Date != null)
{
   query.Append(" AND Orders.OrderDate = @Date");
   paramaters.Add(DbServices.CreateParameter("Date", SqlDbType.DateTime, this.Filter.Date));
}

if (this.Filter.Price != null)
{
   query.Append(" AND Orders.Price > @Price");
   paramaters.Add(DbServices.CreateParameter("Price", SqlDbType.Double, this.Filter.Price));
}

Now, look at the 2 lines marked in red. The filter at the GUI sent Price = 1000 while the DAL object looks for Price > 1000 (remember, this is the client's request).

Not only we've got a mismatch, the coding wasn't trivial nor "easy". We had to know(=remember) what method to override at our OrdersDal.

-- New --

Orders.aspx:

FilterExpression filter = new FilterExpression();
filter.Where(
   Where.EqualTo(Order.Field.IsActive, true),
   Operator.And(),
   Where.EqualTo(Order.Field.Date, DateTime.Today),
   Operator.And(),
   Where.GreaterThan(Order.Field.Price, 1000)
);

EntityCollection<Order> orders = OrdersService.Instance.GetByExpression(filter);
// ... bind orders to our GridView ...

That's it. No mismatch - the GUI programmer can now see exactly what results the Orders Service will return and no need to look at OrdersDal.
Coding was short and fun.

I thought that this small but important infrastructure will be a nice platform to practice a "Real-World" work with TDD. The infrastructure at its current form is working quite well so I know how to API should look in general and what are my "big" problems (Mapping, Resolving db function names and a few more).

Is SEE revolutionary ?

Hardly!
Expressions like languages are all over the place lately:

1. LINQ - to be honest, this is a really great query language but it ruined my Visual Studio .Net 2005!! The product requires some installation that simply is a disaster for a developer station.
2. HQL - Nhibernate. This is actually very nice but I get no errors during writing.
3. eSql - Looks great. is it safe for production? I'm not so sure... anyway, it's all with C# 3.0 and suffers from symptom (1).

I can add additional 2-3 infrastructures to the list but you get the picture.  

So why do I\you still need SEE for ?

SEE is an home-made infrastructure which was developed by the KISS (keep it simple, stupid) principle. I know that there are many folks out there who still write\generate custom Data Access Objects. Integrating SEE in your custom DAO objects will be very simple as the infrastructure gives a solution to a very narrow problem domain. There is no need to learn a new "quotation marks prisoner" language. The developer can enjoy the VS.NET IntelliSense and as you could see in my previous example, the API is very easy to understand.

Moving toward one of the other languages\technologies can take some time as the learning curve can be quite high.

You could SEE with a very small time investment by your side.

Where do you come along ?

I will upload any code I'll write during this coaching lessons so you can see our progress, bit after bit. In addition, I'm going to write a prolonged post after each lesson, to share with you my insights. This is the interesting part though - my infrastructure will change according to your requests (well, some of them anyway, and only the "good" and "simple" ones ;)). Feel free to suggest new features or to change method\classes names\relations. This will able me to practice changes to our SEE infrastructure as part of the TDD practice.

I hope that we'll enjoy the process and learn new things on the way,
Oren.