I am writing a relatively small and simple Windows Service, and using Moles to mock unit tests. Due to the small code, I decided to use Moles instrumentation, rather than segmenting the code with stubs. When I execute any unit test against the moled assembly, I receive an error:
InitilaizationDetectsMissingMonitorDirectory has failed: Test method FtpDirWatcher.Test.FileWatcherTest.InitilaizationDetectsMissingMonitorDirectory threw exception: Microsoft.Moles.Framework.Moles.MoleInvalidOperationException:
Moles requires tests to be IN an instrumented process.
In Visual Studio Test, add the following attribute your unit test method:
[TestMethod]
[HostType("Moles")] // add this attribute
public void Test() { ... }
I'm not sure what it means that "Moles requires tests to be IN an instrumented process." Note the "IN" means this is not the usual "Moles requires tests to be an instrumented process." I have looked back through do开发者_如何学Gocumentation, to see if there is anything I have missed. I am obviously still missing something important.
The target assembly ("FtpDirWatcher") is indeed instrumented by Moles (evidenced by the presence of the MFileWatcher object), and I have the proper attributes in place on the test method. I even tried converting the target property to a method, to no avail. So, what's going on?
This is condensed code, so no criticisms!
using System;
using System.IO;
using System.Linq;
using FtpDirWatcher.Moles;
using Microsoft.Moles.Framework;
using Microsoft.VisualStudio.TestTools.UnitTesting;
[assembly: MolesAssemblySettings(Bitness = MolesBitness.AnyCPU)]
namespace .Test // Test project namespace
{
[TestClass]
public class FileWatcherTest
{
readonly string _invalidDirectory = @"B:\invaliddirectory";
[TestMethod]
[DeploymentItem("FileWatcher.exe")]
[HostType("Moles")]
public void InitilaizationDetectsMissingMonitorDirectory()
{
Assert.IsFalse(Directory.Exists(_invalidDirectory));
// THE FOLLOWING LINE OF CODE THROWS THE ERROR.
// Use moles to detour the MonitorDirectory property's Get
// method to a delegate.
MFileWatcher.AllInstances.MonitorDirectoryGet = watcher =>
new DirectoryInfo(_invalidDirectory);
// Don't use the accessor -- no private fields are accessed.
var target = new FileWatcher();
Assert.IsFalse(target.IsConfigurationOk);
}
}
}
Any help is appreciated!
UPDATE: Added the following build output. Included the bitness setting in the code, above, to show that it should not be an issue.
------ Rebuild All started: Project: Common, Configuration: Debug x86 ------
Common -> C:...\Common\bin\x86\Debug\Common.dll
------ Rebuild All started: Project: FtpDirWatcher, Configuration: Debug x86 ------
FtpDirWatcher -> C:...\FtpDirWatcher\bin\Debug\FtpDirWatcher.exe
------ Rebuild All started: Project: FtpDirWatcher.Test, Configuration: Debug x86 ------
Microsoft Moles v0.94.51023.0 - http://research.microsoft.com/moles - .NET v4.0.30319
Copyright (c) Microsoft Corporation 2007-2010. All rights reserved.
00:00:00.00> moles
Moles : info : metadata : ignoring reference C:\...\FtpDirWatcher.Test\MolesAssemblies\FtpDirWatcher.Moles.dll Moles : info : metadata : incompatible assembly bitness, using reflection only Moles : info : metadata : loading C:\...\FtpDirWatcher\bin\Debug\FtpDirWatcher.exe (reflection only) Moles : info : compilation : output assembly name: FtpDirWatcher.Moles Moles : info : code : found 4 types Moles : info : code : visibility: exported or assembly(FtpDirWatcher.Moles) 00:00:00.37> code generation Moles : info : code : generating code at C:\...\FtpDirWatcher.Test\obj\x86\Debug\Moles\befw\m.g.cs 00:00:00.52> stubs generation Moles : info : code : generated 2 stub types 00:00:00.89> moles generation Moles : info : code : generated 2 mole types 00:00:01.45> compiling Moles : info : compilation : Moles assembly: C:\...\FtpDirWatcher.Test\MolesAssemblies\FtpDirWatcher.Moles.dll
00:00:02.37> moles generator 0 errors, 0 warnings
FtpDirWatcher.Test -> C:...\FtpDirWatcher.Test\bin\x86\Debug\FtpDirWatcher.Test.dll ========== Rebuild All: 3 succeeded, 0 failed, 0 skipped ==========
Try this: http://social.msdn.microsoft.com/Forums/en/pex/thread/176b2fc5-882e-413b-b4d5-10ea6b486e65
Are you using x64?
This is a total face-palm solution. I realized I was executing tests by using the DevExpress Tools for Visual Studio add-in glyphs (icons) that are placed in the IDE code window, next to the test methods and classes. The Moles installer alters the Visual Studio testing tools, to include parameters and switches for the Moles host adapter. However, DevExpress was not modified.
Two solutions are possible:
- Simply execute Moles tests by using the Visual Studio test tools directly
- Modify DevExpress Tools for Visual Studio to correctly use the Moles host
A detailed overview and sample code is on my blog, The Curly Brace: http://thecurlybrace.blogspot.com/2011/05/moles-requires-tests-to-be-in.html
精彩评论