Geek Answers Handbook

Speeding up ASP MVC tests

How do people run their automated tests for ASP MVC?

We currently use our own unit tests of Visual Studio and run them linearly on the same machine. They are too slow to be useful at this time.

Switching to nunit? Distribute unit tests with Incredibuild XGE? Has anyone tried these or other ideas?

Thanks.

+4
source share
4 answers

The problem with MSTest is not the launch speed itself, but the test environment itself. You can run MSTest tests with Resharper, and they are pretty fast. My tests flow against the repository interface, and I make fun of the repository in memory when the controllers are called.

However, controller tests should be very easy: return type (ViewResult, JsonResult) and model type. Not much more (see http://www.arrangeactassert.com/how-to-unit-test-asp-net-mvc-controllers/ ). Test your business-level challenges separately from controllers. Done correctly, in a thousand unit tests it takes just a few seconds.

+4
source

Most of the speed you see is MSTests, which starts the ASP.NET development server every time you want to run at least one test.

I save as much of my application as possible in different libraries outside of my ASP.NET application so that they can be tested independently. This avoids the bumps you take when starting the ASP.NET development server during unit testing.

When the controllers taunt, I see no reason why you could not remove the attributes that tell the testing system to start the development server. After all, is it not the goal to taunt the “external” components?

Similarly, the whole purpose of using repositories for your models is that you can introduce mocking objects for testing. These tests are also not needed by the development server.

As for the views, I would not write unit tests for them. Keep them as thin as possible and check them manually by visual inspection.

A different set of tests may be included for your models and controllers that include the ASP.NET development server. These tests will be part of your integration test suite.

+3
source

changing the scope of unit testing will not do you any good

if your tests are too long, mainly because they connect to a database or web service ...

I suggest you use CI to run all tests, as well as separate tests, for example, the user interface layer should have tests separate from data access tests ...

0
source

Several factors affect the speed of testing: they can be MSTest in fact one of them.

Any of the following may affect the speed of testing:

  • Tests that actually perform db access
  • Disk dependent tests (e.g. reading web.config)
  • Code that is actually broken (for example, countless unnecessary loops, other performance loopholes)
  • Tests that do too much (testing several things at a time) or do not actually test a block

Unit tests, by definition, should be small and fast. Beyond your frameworks, look for other things in the list above that might slow them down.

0
source

More articles:


All Articles