Hawthorne Wins the Grand Final

Hey!

I just wanted to mention that Hawthorne, the AFL team who are sponsored by DWS, won the grand final this weekend!

Kind Regards
Glenn

Google Chrome

As part of the internal work here at DWS, I tried Google Chrome. What I was looking for was another browser that did in-line spell checking; Firefox is the other one I know of and there are likely more. Interestingly, IE doesn’t provide this functionality.

As I looked around this new browser, I went through the comic presentation on the design decisions. It’s quite inspiring and the browser does well for their approach. What I want to talk about today is the sort of thought that went in to this browser.

Threading vs Multi-Process

A stand-out decision was to make each tab a different process. IE, in comparison, treats every tab as a separate thread. If you’re not quite familiar about topics this close to the silicon, keep reading, I’ll expand on how very different these two approaches are!

Threading is all about one process doing multiple things. Threading is often used on the Windows platform. It is a historical decision as much as a technical decision. Some of the key considerations about this are:

• If the master thread dies, all threads die
• There are difficulties to be overcome when threads begin talking to each other or using the same memory space
• Threads have to be monitored and managed

Multi-processing is quite different. It’s about multiple processes all doing their own thing. The multi-process approach is very popular on the Unix platform as well as Unix clones such as Linux. Again, it is a historical decision as much as a technical decision and its key considerations are:

• Processes are managed by the operating system rather than by a master thread
• Processes are self-containing, if all the other processes die, the one remaining continues to function unaffected
• There is no shared memory to manage, although some information can be exchanged using a shared space

Now, what makes one better than the other? For me, it’s all about two competing desires: memory footprint and simplicity. Threads are a smaller memory footprint while multi-processes are simpler to implement. Interestingly, Google went the way of multi-processing and their reasons for doing it appear quite sound. I won’t go in to detail here but take a look at their comic presentation for details.

Focusing on the Tab

Google have also focused greatly on the tab. They think it so important, they put it at the top of the window. Each tab has its own address bar and buttons as well. What’s more, because each tab is a separate process, it’s simple to undock each tab in to a new window.

Speed

People I ask about Google Chrome all say the same thing: it’s fast. A lot of effort has been put in to speeding up the rendering engine as well as Google’s own JScript VM which compiles native code. It all makes a faster browsing experience.

Security

Google sandbox their browser processes. This means that websites can’t change your hosts file to some-very-bad-website.com to steal your credit card number or show inappropriate content. Of course, there are some limitations with plug-ins because they’re not sand-boxed, but the attach surface is greatly reduced.

Summary

So, why do I care about blogging about some new browser? The reason why is because it is another example of people getting together to produce a quality product. It’s not about what makes it so good, it’s about how Google went about creating this product. As a tester/developer, I want to make fantastic cool products that close the gap between people and their tasks.

Kind Regards
Glenn 

Stubs vs Mock Objects

During my presentation on mock objects earlier this week, people started discussing the differences between stubs and mock objects. I wasn’t ready for this question and had used all my Q&A time up already. When I was asked to comment more on this off-line, I decided to discuss it a little here.

I’m not intending to write an essay here. Stubs and mock objects are quite interesting but I only want to give an introduction at this stage. So, with a quick refresher on the differences, here’s what I know…

Introducing a Term

To begin, I’ll need to explain what kind of objects both stubs and mock objects are. For this I’ll need to introduce a term. Since both stubs and mock objects are trying to achieve something similar, they can be grouped together. The phrase I’ve heard most is “Test Double”. The idea is that these objects are similar in some way to production code but aren’t completely identical. Instead, they are like stunt doubles in a movie. Martin Fowler tells us this term comes from Gerard Meszaros, who coined it in his book xUnit Test Patterns.

What is a Stub?

My understanding of stubs has been the same since before I learned about mock objects. The idea is of having a test double capable of satisfying the requirements of testing without the impact of some complex external system. When coded, these stubs normally provide information for consumption by the system under test.

Information within stubs are often hard-coded return values or properties. Their use is intended to satisfy the compilation requirements as well as fulfilling any needs required to test the intended behaviour of the system. The use of stubs is often confined to when production code either isn’t implemented yet or it would impact somehow to use a real object.

Here is a key concept when comparing with mock objects. Stubs are used generally when the real object either isn’t available or isn’t appropriate for testing. In most other situations, the real object is used.

Martin Fowler describes the purpose of stubs as being useful for state-based verification. Given that stubs normally have values and states hard coded, testing takes the approach of ensuring the system functions correctly in certain states.

What are Mock Objects?

I like to describe mock objects as simulations of an object. This description will likely be understood by some people and only work to generate more questions for others. Let me explain more…

Mock objects normally implement an object from end to end. They receive input, perform some process on that input, and generate output. The difference between this test double and a real object is that mock objects have an imaginary processing stage; i.e., it’s processes generate output based on what would happen if the real work had happened.

Let’s look at an example. Suppose I have an interface to determine what sizes a shoe manufacturer supplies as part of each model of shoe. The real object would take the name of the shoe and return all the sizes supplied. It might perform this operation by executing a stored procedure in a database to lookup the record ID of the shoe and match it against a many to many table relationship between shoe model IDs and sizes. It would then format the results in an array and return the results to the calling code.

A mock object would do exactly the same, it’s just that it would pretend that an array given as part of the unit test’s setup was the results of the database’s stored procedure. Let’s take a look at some code:

...
string sizes[] = {"8", "9 1/2", "11D"};
MockDatabase db = new MockDatabase(sizes);

string shoeName = "Puddle Jumper TM";
string shoeSizes[] = db.GetShoeSizes(shoeName);
...
Example 1: Populating a mock object with database information

As you can see, instead of going to a real database, it has some values we have chosen for our test case. Take note, this mock object may be used many times and could use a different set of shoe sizes for each test case. In fact, it could use several sets of shoe sizes within just one test case! This is an important difference from stubs, these values are not hard-coded.

In the background, GetShoeSizes(string) takes the given array and formats it in to the expected representation. On top of this, we could have added features for testing, such as counting the invocations of the method, generating exceptions, as well as ensuring these statistics are all within our expectations. Instead of a silent partner, the mock object becomes co-star, defining and testing our expectations!

Martin Fowler describes mock objects as being used for behaviour-based verification. The input and output are not coded but are instead in part processed (or as I term, an imaginary process), and defines the behaviour of the application.

This point is crucial. It beckons the introduction of contracts within the design of software. As soon as you have test cases defining the expected behaviour, as mock objects do, you are building a contract between the application, the test case, and the developer who is intending to develop the production code. For this reason, test cases should be written to reflect the requirements closely.

Summary

So, hopefully this blog post has helped with the question of what difference there is between stubs and mock objects. We’ve learned that stubs are normally hard-coded substitutes for production code whereas mock objects have an imaginary process which helps to build expectations of how the production system will behave. Also, we’ve learned that stubs work with state-based verification while mock objects work with behaviour-based verification.

Hopefully this has provided an interesting introduction to the area of mock objects. You can read more from Martin Fowler’s essay on this topic at http://martinfowler.com/articles/mocksArentStubs.html, where I did my quick refresh on the differences between these two kinds of objects.

This topic of stubs and mock objects moves in to the space of Design By Contract and Test Driven Design. See my post on Test Driven Design if you’d like my introduction to that space as well.

As usual, keep the discussion going and leave a comment.

Kind Regards
Glenn

Presentation

Well, I did say I was going to be busy. Yes, I’m still here and Quality in Software is still active. Hooray!

These last weeks have seen me feeling like my time has been pretty thinly spread. Nevermind, still, what’s happening?

Well, tomorrow I’m giving a presentation on Testing Components with Complex Associations. It’s a dive in to the world of Mock Objects, patterns, and other things like that. Of course, I’ve held back because my space is only 20 minutes. Quality is such a big topic.

Just lately, I’ve been in a test lead role. It’s been good. I’m surprised just how much I think about my test lead back at Motorola; Chris Lawn. Very dedicated person who I believe has had an impact on how I approach the role of testing.

In the not too distant future? Work, I’m real busy right now, more blogging, and of course one of my favorite professional development activities, reading books. They’re so invaluable!

I’ve been meaning to have a page to share book titles. That will still go ahead. I look forward to sharing book titles with you all as I’m always on the lookout for a great book on quality.

Anyway, for now, it’s back to work. I just got an updated spec I have been waiting for so I’m on the quality trail yet again.

Kind Regards
Glenn