Posts

Onion architecture

Jeff seems to have put it very well in his blog. Much better than I did myself back in December 2006 when I blogged about my "Onion" idea. My mistakes were 01: I was missing a domain services layer. 02: I tried to explain it using a specific example (wizard app with a "process stack" aka "task stack"), and later decided I didn't like the example :-) 03: When I drew my diagrams I showed them as a typical stacked diagram, because my graphics skills are crap :-) Here's my badly put idea of onion layered applications: http://mrpmorris.blogspot.com/2006/12/net-onion-part-1.html Here's Jeffrey's http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ Well done Jeff, very nicely put!

Rhino Mocks, returning a different result every time

[TestMethod] public void Meh() { var mockFileSystem = MockRepository.GenerateMock<IFileSystemService>(); mockFileSystem.Stub(fs => fs.CreateFileStream(null, FileMode.Append, FileAccess.Write, FileShare.None)) .IgnoreArguments() .Return(new MemoryStream()); var result1 = mockFileSystem.CreateFileStream(null, FileMode.Append, FileAccess.Write, FileShare.None); var result2 = mockFileSystem.CreateFileStream(null, FileMode.Append, FileAccess.Write, FileShare.None); Assert.AreNotSame(result1, result2); } This test case shows a problem I was having. The return value of the stubbed CreateFileStream method isn't calculated each time it is called, it is calculated once at the point you defined the stub method and then returned for every subsequent call. The problem with this is that my real test needed to call CreateFileStream twice and get two different streams, the test was failing because the method being tested disposes of the stream it uses; this was resulti

Why are all my Visual Studio unit test results "Not executed"

When I run my unit tests in my project I am seeing a result "Not executed" for every one. I have restarted my computer so I doubt this is some kind of hung process issue. Google has revealed nothing that is not related to load balancing, and I am not load balancing! Solved In order to determine the error you have to do this Open the Visual Studio command prompt Change to the directory where the binary output of your test project is. Type mstest /testcontainer:The.Name.Of.Your.Test.Assembly.dll At the bottom of the output you will see the following text Run has the following issue(s): In my case it was the following: Failed to queue test run 'Peter Morris@PETERMORRIS-PC 2009-02-09 10:00:37': Test Run deployment issue: The location of the file or directory 'C:\SomePath\SomeProject.Tests\bin\Debug\Rhino.Mocks.dll' is not trusted. Now if VS had told me this in the IDE I could have fixed it in minutes! All you have to do is open Windows Explorer and

Silent errors

I'm working on an app which uses a 3rd party library for producing SWF and FLV files. For some reason the trial worked perfectly but when I switched my app to the full version there was no audio output. We'd been looking at this problem for a while, emailing support etc, but just couldn't see what was wrong. It wasn't until I went back to my proof of concept app and ran it that we realised the full version did produce audio, it was just my main app that wouldn't work properly. Then I spotted the error... var compressor = new TVE4(); compressor.LoadSettings(SettingsPath); compressor.SetOutputFile(outputFileName); compressor.EncodeSequenceAudio(Composition.EffectiveProductionAudioFileName); compressor.Key1 = 12345; compressor.Key2 = 54321; (loop to encode frames) Do you see the error? It was only as I switched between the proof of concept code and my app code in the IDE that I noticed the two following lines moving up and down... compressor.Key1 = 12345;

Perceived speed

I'm writing an app which basically performs the following steps in a wizard-like interface: Select an audio file of someone speaking + loads a text script in. Process the audio file and the script, can take about 5 seconds for a minute of audio. Select a character to use in the animation. Select some additional graphics and scene settings. Use the data generated in step #2. Sitting there for 5 seconds wasn't really a problem, not to process a 1 minute audio file. A longer audio file would take a little longer, but 10-15 seconds is okay, isn't it? Well, what if I could make it take no time at all? Obviously I can't, but I can make it look like it takes no time at all. The fact is that I don't need the processed data until Step 5. The user will probably spend at least 30 seconds twiddling settings in each Step 3 and 4. How much processing power does a bit of GUI interaction take? Hardly any at all! So I made Step 2 run in a separate thread. As soon as the user

Data Transfer Objects

My observations on data transfer objects They should not be a one to one representation of your domain classes. Sometimes you want a subset of the information of a single instance, sometimes your DTO will collect data from various instances (starting with an aggregate root ). You might create different types of DTO from the same domain classes based on what the user needs to do. Sometimes the user only wants OrderNumber + DateRaised + TotalValue (to show as a list of orders), sometimes they want the entire order details (including lines) for editing. The domain classes should have no knowledge of your DTO classes. So you shouldn't have any methods such as pubic PersonDto CreateDto(); public UpdateFromDto(personDto); DTO's are not part of the business domain, so you should never do this! The DTO you send out might not be the same type as you get back. For example you don't want the user to edit the order number or the date raised. If there are only a couple of properties

How often should I test?

I am lazy.  I don't mean that I don't work, I mean that I like to get my work done with as little effort as possible.  Writing tests before my code used to look like too much extra work, but I've realised just how much time they actually save me. When you make a small change to something it's very easy to think to yourself "That's such a small change, I can't see how it can possibly fail", what I have also realised is this really means "Despite this being a small change, it will fail and I can't possibly see how". I recently observed a change to some code that introduced a simple if statement, and all existing tests passed.  The problem is that the existing tests only checked the expected behaviour worked (which it still did), but by introducing the "if" statement (and an additional parameter on the method) the developer had changed the expected behaviour under certain circumstances .  Thinking it was so simple it couldn't p