2

I'm debugging a set of WCF services. Initially, I created some unit tests, but since I'm using threading I often receive "Aborted" or "Stopped" tests without any clear explanation why (this is a known bug in Visual Studio).

I found it extremely challenging to debug the services when I can't even read the log output, so I quickly wrote a custom Assert class and converted all unit tests to console applications. This way, I was able to fix a huge number of simple problems immediately that were hard to impossible before.

So I'm wondering if it is a good idea to write unit tests as (fully automated) console apps first and convert them to real (executes when launching unit tests in VS) tests later.

mafu
  • 31,798
  • 42
  • 154
  • 247
  • What ever works (correctly), and is simple is good enough for me :) – leppie Sep 09 '10 at 10:56
  • 2
    AHh, your probably using MS Test... a little advice NUNIT!!! – Zoidberg Sep 09 '10 at 11:01
  • I'm gonna 2nd @Zoidberg on this - I've always been under the impression that NUnit tests were just as simple, if not simpler, than console apps. When threading, include some code to wait until all threads die in the tear-down – kelloti Jan 29 '11 at 17:10
  • You should add that as an answer – mafu Jan 31 '11 at 09:21

1 Answers1

1

if you want to stick to the stand alone console app you can have a one fits all aproach: Change

  • the application type of the MsUnitTest (or NUnitTest) to "Console application"
  • add a public static void Main() that call your unittests you are interested in.

This exe is can run on its own or it runs in the unittest-ide.

I prefer a standalone consolerunner as described in how-do-i-use-mstest-without-visual-studio

Community
  • 1
  • 1
k3b
  • 14,517
  • 7
  • 53
  • 85