Ubuntu

So giving Ubuntu a try this week. After so much fuss getting a Windows server at work with licenses and such, I feel pretty turned off by Microsoft at the moment. Otu at work has been using Ubuntu for well over a year now and I've been meaning to try it, especially seeing as I'd got a new laptop a few months back and nothing to use the relatively new but now obsolete laptop I had. So here I am, this post coming to you from an Ubuntu powered laptop.

May my colleges have mercy on me. lol

Getting Paid to Play Games

The life of a software developer can be a hard one, but now and then you're asked to do something which makes you jump for joy like the kids from South Park when the Terence and Phillip movies comes to town. When you're boss asks you if you've ever read 'Snow Crash' (if you haven't, go read it now) with a glint in his eye followed by 'go and make our services work in a MMORPG', that's the feeling I get.

The Difference between Music and Telco industries

While the music industry continues to moan the loss of traditional revenues, the telco industry is attempting to embrace change. I should know, working on projects like http://web21c.bt.com at the UKs incumbant telco.

I'm a bit fed up of hearing the music industry bitch. If they don't come up with an answer soon, they'll find themselves out of work.

Lack of Support for MsTest

It's franly quite annoying how little support there is for Visual Studio testing. What are Microsoft thinking with the multiple flavours of the product? I didn't realise that some didn't have the test tools, frankly this is scary for our TDD friends. Perhaps considering the support there is for nUnit (not least nCover - theres nothing for MsTest apart from a tool a colleague and I wrote http://sourceforge.net/projects/mstestuncovered) it would worth thinking about migrating.

The Conflict of Test Driven Development and Compile Time Code Analysis

So, I'm sitting here pairing on some code and we write our test which involves generating a method stub. We attempt to compile, but we're thrown a load of errors as we've got our code analysis set to terminate (i.e. do not compile if your code sucks). But I'm finding this furstrating as the code isn't compiling as we're not using the parameters of the new method, but this is because we haven't implemented it yet and I want to see it fail!

So we have to suppress the error to make it compile, and hope to remember to take out the suppressions.

Now that sucks!

TV

I always say I don't watch that much TV, and in many ways this is true. Due to the combination of a bad memory and laziness I would rarely rush home to watch that special show at whatever o'clock. Even the new PVC (the very nice BT Vision) doesn't help as I've only got freeview and I'll be dammed to pay Sky or anyone else for content I'm not going to watch (see above for reasons).

There is some special occasions though when a particular show grabs my attention and pulls me in. Being somewhat of a geek. (Ok, a lot of a geek) this new tend in mainstream sci-fi TV shows is getting the better of me. This weekend I've spent most of the time in front of the TV watching Heros. I'm really enjoying TV recently. These season long plots, fast paced, low key sci-fi shows are getting me everytime. Sure there's shows I can't really stand (Lost?) but still find myself watching week in week out, but I'm happy that we seem to have put sit coms to one side for a while to enjoy character developement and kick ass plots.

Are We Hard To Shock?

I've just read an interesting article on how we've evolved thick skins with regard to bad news. Having grown up in a 24 hour media culture I don't know any different.

http://news.uk.msn.com/zeebrugge_numb_towards_disaster.aspx

Random Thought

People who wear suits cannot look good saying words like 'dude'.

FxCop is dead, long live FxCop

FxCop has been brought into VS2005, although now called the imaginative name of ‘Code Analysis’. The tight integration means that the rule violations are reported in the IDE. Here are some questions I asked myself when playing with the tool...

Q) Looks nice in the IDE, but how do I integrate this into my build process?

A) By cunningly enforcing rules at compile time.

Q) Interesting, tell me more. (Not really a question, I know).

A) Go to the project properties and select ‘Code Analysis’. By choosing ‘All configurations’, then enabling (not set by default) Code Analysis and (here’s the cunning bit), set each rule status set to (compile time) ‘Error’ i.e. code will not compile if a rule is broken.

Q) What if I want to turn off a rule?

A) In the properties, you can enable or disable an individual rule or a whole rule set. Alternatively, if you right click on the compile time error in the error list, you can select ‘Suppress Message’. This generates a file in the project called ‘GlobalSuppressions.cs’ which contains assembly attributes for individual rules.

Q) Will it affect my build environment?

A) If you’re calling MSBuild on the command line, you have to set the FXCOPDIR environment variable (see next Q)

Q) So I still need to install FxCop?

A) Not if you have Visual Studio Team Edition for Testers as FxCop is bundled and can be found here (default directory): C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop

Q) Is there any way to force code analysis or check that it’ being run in the build?

A) Code analysis isn’t set by default, so unless you wanted to create a project template with it set you couldn’t make sure it’s enabled on every new project created. You could check the csproj file to make sure it’s enabled using xPath or otherwise (/Project/ProjectGroup/RunCodeAnalysis = true) or check the MSBuild results in the build report.

Q) How can these rules be shared by the team ... are the rules that are turned off saved into the project/solution file?

A)The rules are embedded into the project file (yes, you have to set the rules for each project) including turned off and suppressed rules via the GlobalSuppression.cs file within the project at the root of the project.

When Good Ideas Go Bad

5 hours later I got this...

Gamma Testing

I was uploading some piccies on Flickr earlier and noticed that along with their logo, there was a subtle 'gamma' logo. I wonder, is this a dig at the empire known as Google and the perpetual beta program?

Thoughts from a train

First of all, it's pretty hard writing from a train where you don't have a seat with a table is pretty hard. I don't think when the engineers were designing the train I'm sitting on thought that the tray for eating would be used for resting a laptop on. On well, it's a minor thing I suppose, I can make do with the shaking, mistaking typing of mine.

So, I'm waiting at Kings Cross for a train to Edinburgh. I'm early as usual (a character trait which forces me never to be late, but always far to early!), so I get a coffee and pick up the metro. Searching, I find no-where to sit and once I finish my coffee I find no bin to put the cup in.

Why is it that we're so paranoid in London that we don't have any bins anywhere. We'd rather contribute to poluting our fair city the comprimise the security. Funnily enough I didn't notice any litter at the station. Go figure.

Keep It Simple, Stupid!

I wrote this a while ago and just rediscovered it -

==================================

I really wanted to show off some of the functionalities of the new BT SDK by integrating it into Windows Media Centre Edition (MCE). However trying to implement the simplest solution in MCE proved to be a performance in itself.

Recently I'd read Adam Bosworth's blog in Joel Spolsky's Best Software Writing I book. As Bosworth said "It was essentially a reminder to a group of very smart people that their intelligence should be used to accommodate really simple user and programmer models, not to build really complicated ones". I felt this was certainly applicable in the case where I was developing an MCE add in.

I went onto read Bosworth's blog with all the comments posted. Bosworth talked about the simplicity of PHP and RSS and the complexity of WS*, SOAP and WSDL. Many of the comments discussed their disagreements with the decision to highlight these items but I feel many missed the point of the discussion in general.

Bosworth says it himself, "software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel cored, able to survive and grow while software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion."

Alan Kay said (and we've heard it around the office plenty of times) "Simple things should be simple, complex things should be possible". We've heard Tim say this plenty of times, but the SDK demo really brought this home for me. We weren't making it simple for the developers who'd be using the SDK. Both capabilities and the .Net SDK were guilty of this. There are arguments as too why this was the case, but at the end of the day it wasn't easy enough and that's what any developer would say when attempting to use our services.

Bosworth talks about how the simple and ambiguous free text search (Boolean logic) won over the seemingly easier query by example. "The engineering is hard, but the user model is simple and sloppy". We have to ensure that we follow this logic. The .Net SDK is there to make life unbelievably simple for the developer. We have to ensure that we hide as much complexity as possible from each abstracted layer so that the component layer can do something cool in one line of code.

Bosworth has concerns regarding WSDL, but remember let's forget about the technology for now and look at the underlining issue. "When it doesn't work, no human can figure out why". We've all had our problems with WSDL and developing on MCE proved equally frustrating. Initially I had to install MCE to get the libraries to develop against and had to develop custom batch scripts to compile and register my add-in. When I was happy with my "Hello, World" MCE add-in, I was ready to develop a BT SDK app but when it came to run the application it didn't work and there was no stack trace, no log file, no acknowledgement that the add-in had even failed. With my limited MCE development knowledge, I had run into a brick wall with reinforced steel, concrete and MCE developers!

Bosworth goes onto discuss programmers who consider code to be a means to an end. "The important issue is the content and the community, not the technology". As mentioned earlier, I originally wanted to do a brown bag on integrating MCE with the BT SDK, but the technology was an issue and so was the lack of content within the community. Developing on MCE felt like developing using COM; powerful, but as a newbie MCE developer, overwhelming.

Bosworth focuses on the value not of the technology but of the content. "The value is neither in the computers nor in the software that runs on them. It is in the content and the software's ability to find and filter content and in the software's ability to enable people to collaborate and communicate about content (and each other)". I feel this re-enforces the comment about the engineering being hard, but the user model being simple. The technology isn't important. Whether it's SIP, Oracle, SOAP or WS* it doesn't matter. What matters is that we get the content that matters to the users who want it (if they're allowed to access it of course).

We've all probably taught out parents or kids to use a computer and the internet and Bosworth reveals something that as engineers we can often forget. "My mother never complains that she needs a better client for Amazon. Instead, her interest is in better community tools, better book lists, easier ways to see the book lists, more trust in the reviewers, librarians discussions since she is a librarian and so on". An awesome SDK, great content and easy delivery isn't enough; supporting tools and communities need to exist to make using the application an experience and too pool the knowledge into a community to expose the power and simplicity of the products that are on the market.

"For the first time since computing came along, AI is in the mainstream". People can argue both sides for this comment, but I believe this comment comes from the ability of software to filter and deliver content to the users efficiently and quickly.

Book Review: Practices of an Agile Developer

For any developer starting out with agile, I'd like to recommend this book. Indeed, for any well practiced agile developer, I'd also like to recommend this book.

I first got wind of Practices of an Agile Developer on DotNet Rocks show 205 where the authors Venkat Subramaniam and Andrew Hunt were interviewed and discussed their new book. There are some great agile books around, though they tend to me more about the way things should be done to be agile, but this book dives more into the mind of a developer on a agile project.

The conversational style makes the book really easy to read with plenty of stories thrown in to help illustrate a point. The use of the devil/angel at the start and end of each point also brought home a point (the devil would recommend something evil yet plausible whilst the angel would say what you might actually want to do).

Any developer on an agile project would probably already know a lot of the points raised, but the bite size chunks along side the easy to read prose makes this book worth flicking through regardless of experience.

Pick up your copy.

The Web21C Information About Me Sample App

Hmm, so what's this service call 'Information About Me'? Well, it's a service that enables an application to store information about it's users. It also have a permission model wrapped around the users attributes so that, if the owner of that information wants to, they can enable read/write access to other users within the application domain.

So, without further ado, go check out the downloads page and get the IAM sample source. You'll have to change the wse3policyCache.config file with one of your own based on your application certificate, then you can get going.

Using the sample, you'll need to create a user using our authentication service (WhiteLabelAuthentication) and then create the attribute with the initial value associated with the user who is now logged in to our authentication service. You can launch another instance of the application and create another user and then have a play around with getting and setting the attributes with different permissions. Watch the log for exception messages coming from the service.

Have fun, and place let me know any improvements to the sample that can be made through the comments.

Cheers.

WPF and the Web21C SDK

So I downloaded MS Expression Blend (Beta 1) the other day and had a little play around. It's a little clunky, but has a lot of potential. I really like the way the design has been abstracted away from the code further then the move to partial classes in Visual Studio 2005.

Using Expression Blend, I created my (awesome) GUI for a sample app I've been working on using the SDK. Added a few buttons, text boxes and the like and then added some on click events. Indecently, this was one of the issues I came across where you couldn't edit the .cs code files behind the XAML and trying to create an event wouldn't create the signatures in the code.

The nice thing about this package is that it creates a Visual Studio project so after doing the design you can open it up in and edit the project in VS2005. From here on in it's the same as any other SDK application: set up WSE, add references and get coding.

The presentation of the application look really nice. I'm happy to see that our SDK can be used in many ways with all of these different tools. Next up is WPF/e.

Cool Tools

A lot of these tools were taken from Scott Hanselman's site hanselman.com, so check that out for more of these cool tools. These are just the ones I've found useful as well as others I've come across. Enjoy.
7-Zip, a free zip utility that's much faster then Windows Zip and much more free then WinZip.
FoxIt Reader, a free PDF reader.
Primo PDF Printer, a free PDF printer.
Virtual Clone Drive, a free tool that allows ISOs to be mounted as if from a DVD Rom.
Notepad++, a free editor that is a made to order replacement for Notepad.
ZoomIt, a free zoom tool, much better then Windows Magnifer and really useful for presentations showing code.
TaskSwitch, a really nice and free replacement for alt-tab.
CleanSourcesPlus, do you find sometimes in Visual Studio that cleaning the solution doesn't get rid of any files? Well with a right click on a folder this app will blow all that away!
CopySourceAsHtml, nice plug in for Vs2005 - copy as HTML so no lose of formatting. Great for documentation, forums or blogs.
CommandPromptHere, a few scripts to add the ability to go straight to a command window with VS tools loaded in a directory from right clicking a folder.
Lookout, an awesome indexed search tool for Outlook.
WSCF, Web Service Contract First - awesome tool for generating stubs for server and client side from WSDL.
Paint.Net, a free and much better alternative to MsPaint.
GhostDoc, quite nice for generating a framework on comments in C#.
CommandLineHere, some tools for adding a button to right clicking on a folder to bring a command line window to the current directory.
FileZilla, a greate FTP client.
Some other tools I'm currently trying...
SlickRun, a command line short cut for apps and web pages.
ProxyTrace, looks like a nice tool to see what SOAP is flying around.

Agile Methods, Team Culture and the Bigger Picture

There seems to be a lot of bad air about agile methods at the moment and a lot of gushing over Google’s working practices. From what I’ve read working at Google sounds great, but for better or worse, most of us working a customer driven industry which won’t accept development and management styles like those employed at Google.

After contemplating on this for a while, I was going to write how I felt it was Google’s culture which affected it’s ways of working and hence following a method probably doesn’t make sense for them. I then thought about how practices from companies such as Google along with agile methods such as Scrum could create a high performing software engineering culture. My thoughts diverged into a group of practices which when used together could influence the culture of a group toward a high performing software engineering team, regardless of the method they apply.

Perpetual Learning

Software engineering and agile both promotes knowledge sharing. Pair programming, especially between different levels of experienced developers can improve the knowledge of those developers. Not to mention the other benefits of pair programming with more thought out code with hopefully better design, better tests and better code.

Within our group, every developer takes turns to present a tool, a technology or host a discussion once a week. This is a great way to transfer knowledge within a group, especially if these sessions are captured and archived for future members of the team or for reference. These sessions have been given the name ‘Brown Bags’ after originally being brought from another group doing the same thing, but over lunch.

Every quarter, Google projects show themselves off their peers. This can be a great way of exposing the great work, new tools and new techniques that have been developed over the quarter to the rest of the group. This could enhance the learning of the group as a whole as well as give teams something to strive towards for peer recognition.

Individual learning is also important. Google give their developers 1 day a week to work on their own projects or their own learning encouraging new projects to spin out of that work. 20% of a developer’s time is a lot to lose, but it should be encouraged to spend a certain amount of time on such endeavours. As well as this, in-between releases agile workers are encouraged to have a period of downtime to unwind, recharge the batteries, do some learning and work on some side projects. Hopefully this will feed back into the teams through new ideas during a project and through the weekly brown bags.

Shared Tools

I’m sure we’ve all wrote small applications to perform a specific task. If a group had a shared, searchable repository this could improve the productivity of the group. Or how about taking that one step further and applying a BSD (http://www.opensource.org/licenses/bsd-license.php) licence? Applying that to the code base and host it on a place such as Source Forge could help developers in the team and all over the world. If your company had it’s own share repository and hosted online this could enhance the company’s reputation in the engineering world.

Common Build, Common Code

Common builds and common code can help the engineering practice of being able to move onto different projects with minimal fuss. If all the code looked the same (as Google employees’ claims) that’s going to help when a team member moves team or a new team is formed. Pair programming can be a good way to converge onto a common code style.

A common build should most definitely include a continuous integration environment on a build box with metrics to fail the build such as code coverage and static analysis. Code should be developed in a test driven development (TDD) fashion to ensure only the function that needs to get written is written.

Prioritised Stack, Failing Fast and Team Communications

Google use queuing theories for their work stack; agile uses prioritised backlogs. These aren’t so far apart. Both are pulling mechanisms where the developer pulls the work off the stack that they want to complete. The only real difference is that a sprint is for a set time period with a prioritised stack so the customer can drive features and delivery.

Short sprints and regular releases also enable a team to ‘fail fast’. It may be feasible to set a time for a team to start a project and after a release it may be seen that a project isn’t working for whatever reason. Surely it’s better to realise this after one release and not after a few years of a project. It’s quite a simplistic view, but the sooner a project can fail, the quicker the business can cut the loses on that and move the teams onto projects which can provide value to the business. Architecture and development spikes are also great for this, setting a fixed time period to ‘play’ with a technique or tool and bring back that learning into the project.

Agile, and particularly Scrum uses daily stand up’s so a team member can communicate the work they are undertaking. This is a valuable time for the team to be able to find any issues early on. Some have said that a daily stand up is a triage with protocol. They may be right, but nether-the-less the team benefits from frequent communication from peers.

Conclusions

Every workplace has a culture, every team follows a methodology. But regardless of those, if practices such as those outlined above are followed a team should hopefully increase its value to the business.

QA in an Agile World

Introduction

So, Quality Assurance (QA), yawn! Security, double yawn! I'm as guilty as any other developer who wants to work on something cool in that I occasionally sacrifice these in order to 'get the job done'. But when is done really done? What can be the effect of skipping QA from a project or even a class within a project? How can we make QA and security easier so that it just happens?

SOA as an Asset

As we move towards a service oriented architecture world, our services are acting more like assets for our business. There can be many consumers of our services both large and small and they may or may not have service level agreements (SLAs) based on the consumption of a service. Therefore, our service is an asset and has value that we must protect.

Excuses

There are many excuses for poor software; Selip suggests the most popular are complex environments, cultural bias, waterfall methods and missing in-house expertise. Cultural bias is one of the more interesting ones as Selip (p7) raises the point that "there is usually no reward or penalty structure related to software quality". Personally, I'm not one for a penalty structure but I'm all for a metric based performance reward either through peer recognition (and a little something extra of course) rather then hidden personal goal/development documents.

Three Facets to Secure Software

Lipner and Howard (p2) discuss what they see as the three facets of secure software: repeatable process, engineering education and metrics and accountability.

Metrics are most impressive and responsive in a continuous integration environment running against the code and not against a document. Static analysis and security based tools should be included in a build as well as using code reviews, threat modeling and paired programming to eliminate issues.

Selip (p8) mentions that all the engineers at Microsoft attend an annual training program in the Security Development Lifecycle (SDL). Engineer education is equally important to running these tools in a continuous integration environment. If the engineers are more informed, they are likely to make better decisions and improve the quality of a project.

Commonly Missed Types of Testing

Continuous integration is great for unit and integration tests, but these tests only go so far. It can't test how easy a system is to use or whether the system is backwards compatible. Projects need to be more conscious of functional and user acceptance testing where the program is handed out for feedback. Projects also need to be conscious of strategies to perform regression testing so breaking changes can be tracked.

When is Beta, Alpha?

Everything these days seems to have a beta label slapped on it, but Selip defines the difference between people bases testing techniques (p20). Alpha testing is performed by those friendly to the development team while beta testing is performed by those in a similar demographic to that of the target audience. So unless you have people you don't know testing your software, you're probably in alpha.

Agile Approach to QA

Depending on their structure, stories generally relate to a piece of functionality. If stories are expressed with Volere Shells, the QA can be easier defined as these are written more with a specific test and priority in mind. These stories relate to a set of unit and integration tests that prove the story and feedback into the tools used within the CI environment to prove the QA.

Conclusions

I think Selip (p8) says it best so I'll leave it to him.

"Believe that all software, whether built in-house, purchased as COTS, or developed by outsourcing, is the work of fallible humans who are prone to making mistakes. Understand that the organization and its stakeholders are highly dependent on high-quality, fault-free software. Expect that requirements, design, and software development mistakes will result in risky software faults. Invest in people, processes, and tools to avoid, detect, and neutralize software faults. Mandate and create incentives for a culture that takes pride in quality, has the skills and knowledge to achieve it, and that aggressively finds and fixes faults."

Lipner & Howard (p11) also suggest that project teams should concentrate on threat modeling, code reviews, using automated tools and fuzz testing throughout the lifecycle. This should be done as a higher priority then penetration testing which is used to define production readiness rather then used to find bugs.

References

Selip, S. (2005), To Err Is Human, So Test That Software, Burton Group, http://www.burtongroup.com/content/printver.aspx?cid=729

Lipner, S & Howard, M (2005), The Trustworthy Computing Security Development Lifecycle, MSDN, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/sdl.asp

Futher Reading

http://www.volere.co.uk

The Trouble of Unit Testing the Consumption of Web Services

Test driven development (TDD) and web services are becoming new standards in the industry, but unit testing against a web service raises issues especially if a hit on the service has a financial or performance cost. During development it may be beneficial to mock the behaviour of a live service.

In the project I am working in at the moment we have had to ask ourselves these questions and we have to continue to ask ourselves how to get the best out of unit testing against a web service. Having been recently introduced to the principle of 'inversion of control', I realised our approach was not that far off of these principles although I questioned whether we still had the right approach.

Issues with building a stub web service

The approach we had taken was too generate web service classes using ThinkTectures' WSCF tool (www.thinktecture.com/WSCF/ ) and ran these web services within local host using fixed ports (on our development and build machines). These generated web methods return a NotImplemetedException by default, so we had to fill these methods out to support our unit tests. This is an architecture discussion in itself: complete these classes; extend them or use helper classes. This discussion arose when the services we were building against were changing on a weekly basis. Completing the classes' meant that every time new classes were generated from the WSDL contract, the code was overwritten which would result in a mass copy and paste job.

It was really a question of extending the web methods or using helper classes. Our thought path was as the web services we were developing were fairly volatile in nature any change could result in a large refactoring task to make sure our mock web service was in step with the live web service.

How stupid should a mock web service be?

Our project had started small; in fact the behaviour from the beginning was more like a proof of concept or an architectural spike then anything else. A small team began building web services and also building a toolkit to consume these services. A four person team had complete control over the project and the architectural awareness may have resulted in overcomplicating our stubbed web services later on.

After the proof of concept, the team continued to build the toolkit to expose the services that new teams taken over to develop. Perhaps the team had too much knowledge of the services they were consuming as the mock web services were considerably complex considering they were to be used for testing only.

A discussion on dependency injection got me thinking that our stubs were too complicated. We should be mocking the behaviour of the live services at the contract/interface level without having to think too hard about how the service is implemented.

These thoughts lead to an increase in a practice that the team had already been practising too a small extend; passing known values in parameters. For this too work, the value would have to be known by the test object and the mock web service. If a certain value was passed the web service would behave in a certain way (throwing an exception for example).

This worked for a time and proved somewhat of a success, especially as debugging a running stubbed web service was a painful exercise; creating a stupid web service achieved the desired behaviour and we could test our toolkit sufficiently without investing too much time in developing a mock framework.

As the services increased in complexity and required data from the SOAP header, this simple passing of a known value was not going to be enough to achieve the desired result. After some discussion the decision was made to pass delimited values across in strings. This way, the service would not have to have the same complexity could behave in the same way by using the delimited data as the live service would if that data was in the SOAP header.

Should unit testing include web service calls?

This leads into a question of should a unit test go as far as actually making a web service call in the first place? Our toolkit contains a logic layer which talks to web service proxy objects and we had a configuration that would create that proxy object with a pointer to the live service, or the mock service on the local machine if the configuration was set to 'test mode'.

We could take this one step further in an attempt to improve our build time. When generating a web proxy class, if our configuration was such, we could instead build a object that contained the stupid mocked behaviour in a known assembly. This would almost certainly cut the build time as the code would not have to go through the web service stack several hundred times to complete the test list.

Using this technique means there could be an inherent risk that the web service stack is not being tested at all. This is bad for code coverage, but if the project also had live integration testing this could be seen as an acceptable risk to take within a unit test.

For this to work, the mock objects would have to be maintained as the live services evolve, although this also holds true for the mock web service.

Sharing test data with a mock web service

There is another advantage to not using a web service stack in the unit testing and that is the ability to share test data. When running unit tests with a mock web service, the code is running in a different assembly, and hence has trouble sharing resource as the only way to communicate is through the web service. Sharing a database for test data is one possible answer to that, but its quite a significant hit to use a database if the project does not use a database like our toolkit.

A file on the same machine or even a key/value paired web service could also work but this comes with its own maintenance issues. Sharing a file seems easy enough, but both assemblies would have to know where that file is, and what if someone comes along and checks out the code from source control it should work straight away without configuring. Will that file always be in the same place; probably not. As for setting up a key/value pair web service; well you might as well set up a database.

If the mock object is running in the same (or referenced) assembly, it can have access to the same data resources as the tests and then that data need only be maintained in one place. This could also open up more dependency injection opportunities for the mock web service where any behaviour could be set during run time.