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
"drozd" <(E-Mail Removed)> wrote in message
news:94898fc3-80f3-46a7-a1de-(E-Mail Removed)...
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.
On Jul 28, 5:40 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
wrote:
> 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 communityhttp://community.OpenNETCF.com
>
> "drozd" <drozdow...@gmail.com> wrote in message
>
> news:9793a2d0-0771-466f-8ba9-(E-Mail Removed)...
>
>
>
> > 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
Similar Threads
