cottsak / controllertests Goto Github PK

Like LocalDb, InMemoryEventStore and one for RavenDB if it adds something to RavenDB.Embedded.

There should be examples that show how to set up different types of embedded stores and they should reference these helpers.

When I have this:

var response = Get("/api/whatisyourname");

I would like to have this too (or something similar):

var response = Get("/api/whatisyourname", headers: { {"dev", "fosdfnsoajfnaosdj" } });

I have a need to send headers into requests.

because it's handy with a TDD flow

A common problem is updating the tests packages.config from Microsoft.AspNet.Mvc 5.2.2 to Microsoft.AspNet.Mvc 5.2.3. Perhaps we can use a version range https://docs.nuget.org/create/versioning for this package in https://github.com/cottsak/ControllerTests/blob/master/ControllerTests/ControllerTests.nuspec

Rob suggested to .Flush() and .Clear() inside the Post() helper thus simulating the OnRelease() behaviour. We could even reuse the delegate passed into OnRelease() so that it's not duplicated in the test.

Currently the life cycle management that's baked into this library works well with the way xunit does things however NUnit is different. Internal instances leak from test to test when using NUnit so it would be great to see some first class support for NUnit.

Some MVC work means that the controller is not the entry point: think BaseController or BasePage - things that are used directly on views, particularly layouts. Since these don't have a specific controller action entry point, how do we test these?

Does it make sense to expand this framework to allow the SUT to be any type/interface such that the ActAction()/InvokeAction() can be called against any method and still have a 'real' IoC container integrate the test completely down to the real database? This way we could pull out an interface used in say BaseController, test one of it's methods and expect the rest of the dependencies to be real and integrated against the real db. Or does this move too far from the notion of a Subcutaneous Test? One could argue that in the spirit of Subcutaneous Testing we're ok, because we're still trying to stay as close to the surface as pragmatically possible.

Like is suggested in #6, some tests may need to invoke more than one controller action. If this is true it's likely those two or more actions are not from the same controller. As it is currently designed, this infrastructure does not support that scenario. Perhaps it makes sense to allow the InvokeAction() method to specify a generic argument for any controller thus giving th test a lot more flexibility?

The 5a0aa8b means that a test might only have one controller call which is fairly limiting.

The set up of a test may need to get some result from a different controller call and therefore InvokeAction() instead of ActAction() seem more appropriate. Tests like this (multiple controller calls) are more complete in terms of real user interaction anyway so should be encouraged not discouraged.

Implementers can simply use a base type for tests that need to use only a single thread for certain tests, and decorate that type if they use NCrunch. This package shouldn't force a dependency on NCrunch for everyone.

For example, using EmbeddableDocumentStore, I don't need to worry about the threading issue as the tests can run in parallel - everything is setup and torn down inside each test. I don't have the "transaction" concerns of SQL store tests.