Compact Framework MSTest unit testing.

  • Thread starter Thread starter drozd
  • Start date Start date
D

drozd

Hi,

How do you approach managing MSTest unit tests in smart device
projects (VS2008)?

Do you keep 2 separate test projects
- one set up to reference the smart device test framework
- another using the full framework one
with shared unit tests added as links to the other project.

Or do you only maintain one project and two separate test run config
files?

So far I've been going with the first approach, but it's really
annoying to have to "Add as link.." every time I add a new test class
and also to constantly unload/reload one of the projects (because VS
doesn't like tests with the same name/id loaded at the same time).

The problem with the second approach is that you can't really use the
TestContext in the test classes, because running the tests with the
other test run config will get you:
" System.ArgumentException: Object of type
'Microsoft.VisualStudio.TestTools.TestTypes.Unit.UnitTestAdapterContext'
cannot be converted to type
'Microsoft.VisualStudio.TestTools.UnitTesting.TestContext"

What's your take on this?

Best regards,
Michal
 
I'm not clear why you need the desktop test application. We use MSTest a
lot, and we simply have a device unit test project with a single
testrunconfig file.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
Don't you find running the device tests take a lot of time? With
deploying to the device/emulator and getting the results back?

Running the tests using the desktop test runner is much faster in our
case, so we run them on the device less frequently along with
integration tests.
 
Yes, they're painfully slow on the device, and you can't debug them either,
which makes them actually far less useful than they should be, but no, we
don't run them on the desktop. My typical cycle is that I have a console app
test harness (yes, really) that I use to write and debug the tests. One
that works, I convert it to a true unit test and check it in. Once checked
in, the speed is far less of an issue, since the TFS server just auto-runs
all of them on every check-in. Basically we're relegated them to being for
testing regression, not for an entry point for development (which is how I
use them on the desktop).


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



Don't you find running the device tests take a lot of time? With
deploying to the device/emulator and getting the results back?

Running the tests using the desktop test runner is much faster in our
case, so we run them on the device less frequently along with
integration tests.
 
I think you're over complicating this. You need to ask yourself, "does my
code need to be run on a device?" if the answer is no - and it usually is
no, as few people actually test UI code, then simply setup a device test
project(s) that runs on the desktop. Usually integration tests run as a
nightly build anyway.
 
Back
Top