Quality is infectious

In his recent post - Quality-Speed Tradeoff — You’re kidding yourself, Ron Jeffries has explained how high quality is mandatory in order to achieve high delivery rate.

There are many reasons for quality issues in a product, inherent technical complexity, lack of skill or just plain laziness. However an over looked factor that really hurt quality is pure pressure. When the pressure to deliver rises above a certain level (which vary for people and teams) the team starting to cut corners. When pressed developers will deliver. However we are not magic workers. When pressed we usually starts by working longer and harder, but when that's not enough, the only option left is to compromise current quality in the hope that part of the work can be delayed after the delivery. The mistake involved is the belief that after the release there will be time to fill in the blanks so to speak. naturally there is never enough time. In the agile community we even given those cut corners a glorified name, we call the work we should have done "Technical Debt".

Bad Quality is Infectious

The real problem is that bad quality is infectious by nature. It can starts by maybe skipping a needed refactoring, it might start by not writing  unit tests for a given component (assuming we will do it later) but very soon islands of low quality code start to form. As time goes by these islands have a tendency to grow. In a large enough code base they hide themselves for quite some time. They are always discovered at an inconvenient time when they affect work being done but when there is no time to actually fix it, so another workaround is coded, and again quality suffers just a little more. So they grow and grow until bigger problems starts to show, suddenly the escaped defect rate has significantly increased, adding new features become harder and takes longer. And quality continues to deteriorate until something is decided to be done about it. The problem is that by the time we reach the this stage the cost for fixing the issue is high.

Good quality is also infectious

The good news are that good quality is also infectious, most programmers (at least those I know) really want to do a good job and achieve a high quality code. So it doesn't take much effort to keep us on the high quality road. I have seen cases that a single team member by not compromising quality, cause the rest of the team to follow, even at points when pressure was high.

 

 

So the morale of the story is very simple, quality for me is mainly a state of mind. The moment I accepted the fact that by trading quality I always but always LOSE (and constantly reminding myself of this) I find it easier to achieve better quality. The up side is that I saw how this kind of approach infects others as well.

Read more »

Posted in: Development Practices,Random Thoughts

WPF Testing - Part I

Automating GUI testing is always a tricky business. In fact its so hard that people tend to mark it off as too hard to bother with. I believe however that this observation is not correct.

During one of my consulting gigs I was starting to instruct a new team on the concepts of unit tests and since they working on a real product they actually have some GUI involved (imagine that).If that's not enough they are using WPF as their framework of choice. I on the other side cant claim to be a GUI expert (to say the least) and my hands on experience with actual WPF code is, well, close to nothing.

I couldn't leave it at that, so I invested some time in actually trying to figure out how one can write tests for WPF based GUI. This post (which hopefully will be followed by some more) will demonstrate my finding on the matter.

First scenario I wanted to test was how I can trigger an event using code instead of a person clicking on the GUI. For that (and probably for the following examples as well) I constructed a small application that looks like this:

As you can see for now I have a big empty window with a single button and some text fields, but for now hat will be enough. In order to achieve what I'm doing I'll be using the Isolator framework, and I will try keeping my design as simple as I can (I know that there are many patterns out there that probably reflect a much better design scheme, but I really like to address the pressing need of the common programmer and not resort to fancy designs patterns at this point)

Firing a mocked Event

As I said, first I want to explore how to test an event handler wired to a button. i.e. to simulate a user pressing a button and check that the correct logic is executed. for the purpose of this demo I assume that my GUI is backed up by a business logic layer that will handle the actual business logic, and since that should be tested separately,  all I want for now is to make sure that the proper logic from that layer is called.

so here's the implementation of the business logic:

internal class BusinessLogic
{
   void GetResult()
   {
       throw new NotImplementedException
           ("no logic yet");
   }
}

As you can see noting much in there, in fact since I'm not interested in the buisness layer at this point the implemantation is not yet ready and all i have is a an empty

and here is the the window source code:

public partial class HurtFundsMainWindow : Window
{
   public HurtFundsMainWindow()
   {
       InitializeComponent();
   }

   private void GetResults_Click(
       object sender, RoutedEventArgs e)
   {
       BusinessLogic logic = new BusinessLogic();
       logic.GetResult();
   }
}

Again at this point i dont have much, only a simple event handler for the button click action that will delegate all logic into the business layer. Note that i'm not using any dependancy injection pattern and I'm not working against an interface at this point. (my application is so simple that I really don't see the need for doing that. I assume that when the application evolves the need will make me evolve the design as well)

and here is the actual test code:

[TestMethod]
[Isolated]
public void Clicking()
{
   //Create the fake business logic and inject it into production code
   BusinessLogic fakeLogic =
       Isolate.Fake.Instance<BusinessLogic>();
   Isolate.Swap.NextInstance<BusinessLogic>()
       .With(fakeLogic);

   //Create the fake button
   Button fakeButton =
       Isolate.Fake.Instance<Button>(Members.CallOriginal);
   //inject it into production code
   Isolate.Swap.NextInstance<Button>()
       .With(fakeButton);
   //replace the button event wiring
   Mock mockButton =
       MockManager.GetMockOf(fakeButton);
   MockedEvent handle =
       mockButton.ExpectAddEvent("Click");

   //create the window
   HurtFundsMainWindow wind =
       new HurtFundsMainWindow();

   //fire the mock event
   handle.Fire(wind, new RoutedEventArgs());

   Isolate.Verify.WasCalledWithAnyArguments(
       () => fakeLogic.GetResult());
}

Not very trivial so lets see what's goes on here.

the first step in the test, is creation of the fake business logic, i create the fakeLogic and using the Swap ability I ask the Isolator framework to replace the next created instance of business logic with the fakeLogic (check this for further details).

Second step is doing the same for the button that will be created, after that I also fake the actual event wiring done by WPF and put my hands on a faked handle which I later use to fire the event. (note the event handling is done using an older variant of the Isolator API. I hope that in the near future the proper API will be added to the AAA syntax as well)

Next comes the actual executing. I first create the window, and then I use the fake handle to trigger the event.

At the end of the test I verify that the GUI actually calls the proper logic method (in this case the GetResult() method).

That's all for now, while this is only a basic scenario, the principles shown here can be adapted to handle much of the event system of the WPF system. If you have any questions feel free to leave a comment.

Read more »

Posted in: GUI Testing,Isolator,TDD,tools,Unit Test Patterns,WPF