TestDriven.NET by Jamie Cansdale

I installed above mentioned addin on VSA 2005/ Tablet SP2 RC1

All tests cases worked except.
1) Cannot run a whole test fixture by running inside the class but outside any methods.
2) call to MONO, was not tested because I don't have mono.

Thanks for an excellent product.

JDM

Works in 2005 (with the caveat mentioned above), but doesn't load in 2003, so I have to keep installing/uninstalling if I flip between the two.

Jim

If you have the xmlns for the configuration file set, the addin blows up with this exception.
------ Test started: Assembly: PointBase.Core.dll ------

TestCase '' failed: The argument type 'System.MarshalByRefObject' can not be converted into parameter type 'TestDriven.TestRunner.Framework.ITestListener'.
System.Runtime.Remoting.RemotingException: The argument type 'System.MarshalByRefObject' can not be converted into parameter type 'TestDriven.TestRunner.Framework.ITestListener'. ---> System.InvalidCastException: Object must implement IConvertible.
at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider)
at System.Runtime.Remoting.Messaging.Message.CoerceArg(Object value, Type pt)
--- End of inner exception stack trace ---

Server stack trace:
at System.Runtime.Remoting.Messaging.Message.CoerceArg(Object value, Type pt)
at System.Runtime.Remoting.Messaging.Message.CoerceArgs(MethodBase mb, Object[] args, ParameterInfo[] pi)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at TestDriven.TestRunner.Framework.ITestRunner.Run(ITestListener testListener, ITraceListener traceListener, String assemblyPath, String testPath)
D:\svn\MutantDesign\trunk\Copy of TestDriven.NET\TestDriven.TestRunner\ThreadTestRunner.cs(64,0): at TestDriven.TestRunner.Runner.Run()


0 succeeded, 1 failed, 0 skipped, took 0.00 seconds.


----------

Sample .config file.

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<connectionStrings>
<add name="ConnectionString"
connectionString="Server=server;Integrated Security=True;Database=database"
providerName="System.Data.SqlClient" />
</connectionStrings>
</configuration>

this release even works on my screwed up laptop (I posted some time ago about no release working on my laptop). So I am happy.

Will try the tests soon.

Thanks for a great plug!
/mawi

Hi there,

it can be annoying to locate the test one is working towards, and right click. Would it be possible (or is) to type a command into the commandline with the name of the method?

Would be a huge help. Also setting to test with debug would be just awesome.

> At the moment the installer is completely silent (expect it
to just exit when you open the MSI).

Who's bright idea was that?

Hi,

I´ve been using this Addin for a long time now, but I´m still using the 0.5.120d version. The reason being that later versions never seem to run the same number of test cases as I´m expecting. For instance my current base of tests number 296 according to the NUnit GUI with 282 run and 14 skipped. When I run these with the 0.9.482d version of NUnitAddin( by right-clicking on the project and selecting Run Test(s)) I get only 195 succeeded and 7 skipped?!?! What gives? Am I doing something wrong here? This works with the 0.5.120d version though.

Regards,
Dadi.

Like Jim Arnold, it didn't start for me on my VS 2003 install under Win2k. I guess I'll go back to using an older build...

I am trying to test classes that inherit from classes in other projects. The addin cannot find those referenced classes, even though they are in the same directory as the test.dll.
i have tried everything I can think of and it still cannot reference the classes. Any suggestions?

The NUnit-addin seems to be generating a lot of debug output in the release build. This makes debugging using Debug/Trace.WriteLine, OutputDebugString et al difficult, are there any plans to change this behaviour?

.: t1 :.