It’s funny, the book was mentioned in an episode of “In treatment”, and 60 seconds later I had purchased the book and had it on my Kindle.

Malcolm describes how we all make initial assessments of everything and everyone. The book explains when this ability is not to be trusted and when it is to be trusted.

I found it especially interesting how, for example packaging can change our entire perception of a product. It also explains how we often let our first impression of a person unconsciously affect our interactions with that person.

In essence the book is about decision making, a process that I’ve find to be hard to capture in text. It’s an interesting read and very inspiring, but it is more of a food for thought book than a practically focused guide.

I found it too long, to be honest. It covers both testing and agile principles. For me a better fit would have been if it only focused on testing, implying that I am not the target audience. For the Agile part I would recommend other books on the subject.

The testing parts, however, worked as a muse for my thoughts. It wasn’t long before I was thinking of how I could apply the different aspects mentioned in the book. For instance the book suggests that if the test suite start taking too long to run, it could be split into a quicker suite run each check-in (or my preference each compile) and a longer suite that runs in a build. I realized that most teams I know of would have a hard time splitting their test suites up into quick feedback suites run each time the code compiles and a longer list which run each night. This ties back to some of the problems with TDD where early practitioners risk just producing test after test without considering their value.

Another idea I had while reading the book was that it could be quite easy to produce a test suite for a REST-api using curl and a set of script-files. This suite could easily be automated as well, without need of much programming experience. Then again, it’s not difficult programming either.

The book suggests thinking of different types of tests as features are implemented. Which is good to have as a sort of checklist, and I agree that features should be considered from as many angles as possible for risks or if they can be implemented simpler. However I do not see this as a tester activity or a “programmer” activity. I see it as an obligation for everyone in the team. I do greatly agree with “the power of Three”.

I believe that the book could have been shorter and more concise. Also I could argue that the book isn’t a practical guide, but rather an introduction to agile testing. With this I mean that you shouldn’t expect concrete examples of how to set-up an automated regression test suite. It will however greatly describe the benefits of one and suggest that not every test is suitable for automation (I can see how it’s easy to get carried away with automation).

Despite the fact that I didn’t enjoy the book as much as I had hoped for I would still recommend reading it. However I would recommend readers whom want to focus on the Agile processes to read other books on Agile instead of the chapters discussing processes.

He makes a valid point. I started objecting to using mocks when it was pointed out to me that most of the tests produced with mocks weren’t readable. They typically don’t follow AAA (Arrange Act Assert), and thus work poorly as specifications. But it’s not the mocks, it’s how understandable the test is as a specification. Is it easy to understand what the test does?

If I look at a test 5 months from now, and it is unclear what its testing and how its testing it. Then the ROI of developing that test is lower than it could be.

This change allows the synchronization to ignore hidden projects, contexts and tasks.

For Contexts and Projects this is straight forward. However in Tracks, completed and hidden tasks are left out of the listing of tasks. This means that a task that is left out in Tracks is either deleted or completed.

Previously in Shuffle we just marked these tasks as completed. However now we can handle them properly. Below is a flowchart of how the suggested synchronization process of tasks works.

The flow-chart starts in a state where the tasks are downloaded from Tracks, then it’s compared to the entities in Shuffle by the chart.

The interesting part here is that the check if a task is completed or deleted is a remote check, which means it’s slower. Also any task not in Shuffle but in Tracks is naturally added to Shuffle.

I’d appreciate feedback on this, before I mark the task as Completed in Shuffle.

This is what’s coming:

• Support for small screens, such as the HTC Tattoo
• You can change Synchronization settings without having connection.
  • Previously settings were verified by connecting to Tracks before saving. Now there is a test button to test the settings. Allowing you to change them when offline.

There’s also some work in progress that hopefully will be in the same release. We’re working on a  model change that will help the synchronization process. No longer should the synchronization process cause un-recoverable deletes, and support for ignoring hidden and completed contexts and projects is underway with it as well.

There’s a lot of work to do still, but I wanted to give a heads up that something is happening.

These external actions are accessed through Google’s API, and there are some posts about how to test on Google AppEngine.

Here is an example by AppEngine Fan where he uses Mocker to mock out the external API calls. An approach that shows the power of the mocking library, but to my taste it results in too much code, and too much details about the mocking framework in the test making it harder to read. This ties back to a previous post I wrote about testing without Mocks.

What I wanted was some way to keep my original code intact and still have a pretty self explanatory test.

After some more research I found out that all API calls in the Python SDK are done through a proxy map. Allowing you to replace the behavior of AppEngine with your own, stubbed behavior. This method is used in this example (that still uses the mocking framework), and also this post on the user group was that location where I first noticed it.

This made me dig through the source code available in the SDK about how exactly this stub map worked. What I noticed was that if you started using the stub map, you needed to setup all the stubs.

As far as I could tell there was not means to replace just a single stub and let the map remain otherwise intact. Which was a bit of a trouble for me. One of the reasons I researched it was because I didn’t want to have tons of setup code in my tests.

Since my test code is important I thought I’d show how I want my tests to look like.

Requirements for good test-code:

• Easy to read (Arrange-Act-Assert,Minimal setup code in the test)
• Fast execution
• non-fragile (black box testing the most external interface accessible for testing)

I want specific events in JS-Analytics to send an email to the administrators of JS-Analytics. The use case is covered with testing, but I wanted to add a test for this new requirement.

Here is what the test looks like:

    def test_given_a_new_project_an_email_is_sent_informing_the_admins(self):
      request = HttpRequest()
      request.user = User(username="…", user=users.User("…"))
      request.method = "POST"
      request.POST = {"title":"test"}
      index(request)
      self.assertEqual("project created", self.getMessages()[0].subject())
      

As you can see I wish to use the Log pattern for test sent messages. This allows me to check the sent messages in order. There is a method that allows me to access a copy of all sent emails, with their complete structure. Allowing me to assert different aspects of the emails.

To support this I created a base-class that adds the behavior I want as setup code. This setup code is generic and only specific for AppEngine aspects of the code. Here is the structure:

The base-class called ServiceTest sets up the stub map. I added two stubs that change the behavior from the normal stubs. These add support for setting content that will be accessed through the URLFetch service, and the logging of email messages.

Since no call ever cross the service boundary to actually do anything, the execution time isn’t compromised.

Here is an example of the setContent usage:

    def test_fetching_arrangement_example(self):
      self.setResponse("http://url-to-be-fetched", "fake-content")
      request = HttpRequest()
      result = view_that_does_fetching(request)
      self.assertEqual(result.content, "fake-content")

As you can see its pretty straight forward to Arrange the which content should be returned where.

This structure should be so generic that anyone could use it, so I added a copy of my base-class free to use by others.

We have been struggling with a build error lately, where the compilation works perfectly in Visual Studio, and in our case it also works in some MSBuild builds but not in this specific build. By that I mean that two builds are compiling the same code, with the same dependencies and compilation flags, yet one fails and the other doesn’t.

The error message given is:

D:\Invoicing\UQList.xaml(55,167): error MC2000: Unknown build error, 'Method 'add_PropertyChanged' in type 'UsageQuantityPresenter' from assembly 'ServiceManagementApplication' does not have an implementation. Line 55 Position 167.' 

If we look at the buildlog.txt produced by MSBuild in the failing build, we can find something similar to this:

  Input file 'D:\Invoicing\UQList.xaml' is resolved to new relative path 'Invoicing\UQList.xaml' at directory 'D:\'.
D:\Invoicing\UQList.xaml(55,167): error MC2000: Unknown build error, 'Method 'add_PropertyChanged' in type 'UsageQuantityPresenter' from assembly 'ServiceManagementApplication' does not have an implementation. Line 55 Position 167.'
  Input file 'D:\Trait\TraitsView.xaml' is resolved to new relative path 'Trait\TraitsView.xaml' at directory 'D:\'.
...
  Generated BAML file: 'D:\obj\Release\Themes\luna.normalcolor.baml'.
  Generated BAML file: 'D:\obj\Release\Trait\TraitsView.baml'.
  Markup compilation is done.
Done executing task "MarkupCompilePass2" -- FAILED.
Done building target "MarkupCompilePass2" in project "ServiceMangementApplication.csproj" -- FAILED.

In the XAML we are depending on the UsageQuantityPresenter to implement INotifyPropertyChanged, which it does. However it also implements other interfaces and does inheritance of a base-class.

This is what it looked for for us:

/// <summary>
/// UsageQuantityPresenter
/// </summary>
public class UsageQuantityPresenter : EntityViewPresenterBase, IUsageQuantity
{
...

The EntityViewPresenterBase (I hate that class name by the way) implements INotifyPropertyChanged.

The solution was found in the following forum tread: http://social.msdn.microsoft.com/Forums/en/wpf/thread/00907c94-c6b2-4bf1-98f9-113c5c4392d8

It states that you should add:

<AlwaysCompileMarkupFilesInSeparateDomain>true</AlwaysCompileMarkupFilesInSeparateDomain>

to the .csproj file with the XAML files. Doing this makes MSBuild happy again.

In general it was a good read. Since it’s American it tends not to be very concise, sometimes over elaborating or using constructs of words that could have been shorter. This is normal.

It describes among others how a Checklist somehow can unite the team for the task ahead.

Around chapter 6 it gets really interesting. It’s where it starts discussing what constitutes a good Check-list. Where it divides checklists into two different types: Read-do and do-confirm. To be used in different scenarios. The Read-do is a simple follow this checklist and do the things on it. The do-confirm list is a do some work, then verify that it has been done. In a team verification is done verbally.

It also explains how checklists are used in different industries. What I found interesting was the air-line industry that tests the checklists in flight-simulators. Which begs the question: When did you last execute tests on your software documentation?

The book also describes, among other benefits of checklists, how checklists can increase the communication in the team, by adding communication check-points. One thing that I found missing, was that checklists can help team-members to focus. By having items written down, they don’t have to worry about “not remembering them”, thus freeing up memory space for the task at hand. At least this is the Getting Things Done theory for checklists freeing up focus.

It’s remarkable, the results these checklists demonstrate when used in surgery. And for the question “Would you want the checklist to be used if you were the patient”, my answer is “yes”.

I work with distributed systems, flaky connections and clients capable of being online to collect data to then take it offline. Most clients work with the assumption, you cannot be online all the time.

Now Google’s move into the TV-market marks the beginning of an era where the Internet is just as available in homes as the TV-network. With that I mean that homes have stable available Internet with enough bandwidth to stream video and audio just like the TV-network.

It’s been predicted that just like the radio and TV, the Internet will become a Utility service, and I think that Google’s market entry marks the beginning of just that.

It will be interesting to see how software services will change as this becomes a reality.

So this is how to do it:

First we create a ResourceManager that will handle our localization

class LocalizedResourceManager : ResourceManager
{
  public override string GetString(string name)
  {
    return String.Concat("Client.Telerik.", name).Localize();
  }
}

And then, in an appropriate location we set the default Resource Manager for localization:

LocalizationManager.DefaultResourceManager = new LocalizedResourceManager();

There you have it, short post, but someone pointed out to me that people would like to know these things before they purchase component libraries.