Help with SpecsFor and Integration Testing

[ChuckBryan]

I am using SpecsFor to help with integration testing. I am also using NCrunch and Mediator.

I think my initial problem lies with Structure Map registrations of my various Handlers. I am using a fairly standard Registry class for Mediator: I am also using a "Mediator Behavior" for SpecsFor: However, it appears (based on the white dots) that my Handler is never hit: When I look for this Handler Class in the output of "What do I have" I find: What I think is happening is that AutoMocking is not resolving, so, it is creating a mock object. The "Send To" doesn't resolve the concrete Handler Implementation.

Any suggestions on what I might be missing?

Thanks

Chuck

[MattHoneycutt]

Is this project something you could share with me via Github or Bitbucket?

On Mon, Apr 11, 2016 at 8:34 AM Chuck Bryan notifications@github.com wrote:

I am using SpecsFor to help with integration testing. I am also using NCrunch and Mediator.

I think my initial problem lies with Structure Map registrations of my various Handlers. I am using a fairly standard Registry class for Mediator: [image: image] https://cloud.githubusercontent.com/assets/117843/14428615/c75d4424-ffc7-11e5-9c6d-cab8818314d7.png I am also using a "Mediator Behavior" for SpecsFor: [image: image] https://cloud.githubusercontent.com/assets/117843/14428660/f446bc18-ffc7-11e5-82d9-5770aaa4561a.png However, it appears (based on the white dots) that my Handler is never hit: [image: image] https://cloud.githubusercontent.com/assets/117843/14428693/18857736-ffc8-11e5-962b-daea76b18530.png When I look for this Handler Class in the output of "What do I have" I find: [image: image] https://cloud.githubusercontent.com/assets/117843/14428715/44597510-ffc8-11e5-8f4e-feb00f4231ae.png What I think is happening is that AutoMocking is not resolving, so, it is creating a mock object. The "Send To" doesn't resolve the concrete Handler Implementation.

Any suggestions on what I might be missing?

Thanks

Chuck

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/MattHoneycutt/SpecsFor/issues/95

Matt Honeycutt Pluralsight Author & Senior Web Application Architect [image: Heroic Applications] http://heroicapplications.com/ pluralsight vids http://www.pluralsight.com/author/matt-honeycutt | blog http://trycatchfail.com/ | website http://heroicapplications.com/ | @matthoneycutt http://twitter.com/matthoneycutt

[ChuckBryan]

I can put it on a private repo in Bitbucket.

On Mon, Apr 11, 2016 at 9:53 AM, Matt Honeycutt notifications@github.com wrote:

Is this project something you could share with me via Github or Bitbucket?

On Mon, Apr 11, 2016 at 8:34 AM Chuck Bryan notifications@github.com wrote:

I am using SpecsFor to help with integration testing. I am also using NCrunch and Mediator.

I think my initial problem lies with Structure Map registrations of my various Handlers. I am using a fairly standard Registry class for Mediator: [image: image] < https://cloud.githubusercontent.com/assets/117843/14428615/c75d4424-ffc7-11e5-9c6d-cab8818314d7.png

I am also using a "Mediator Behavior" for SpecsFor: [image: image] < https://cloud.githubusercontent.com/assets/117843/14428660/f446bc18-ffc7-11e5-82d9-5770aaa4561a.png

However, it appears (based on the white dots) that my Handler is never hit: [image: image] < https://cloud.githubusercontent.com/assets/117843/14428693/18857736-ffc8-11e5-962b-daea76b18530.png

When I look for this Handler Class in the output of "What do I have" I find: [image: image] < https://cloud.githubusercontent.com/assets/117843/14428715/44597510-ffc8-11e5-8f4e-feb00f4231ae.png

What I think is happening is that AutoMocking is not resolving, so, it is creating a mock object. The "Send To" doesn't resolve the concrete Handler Implementation.

Any suggestions on what I might be missing?

Thanks

Chuck

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/MattHoneycutt/SpecsFor/issues/95

Matt Honeycutt Pluralsight Author & Senior Web Application Architect [image: Heroic Applications] http://heroicapplications.com/ pluralsight vids http://www.pluralsight.com/author/matt-honeycutt | blog http://trycatchfail.com/ | website http://heroicapplications.com/ | @matthoneycutt http://twitter.com/matthoneycutt

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/MattHoneycutt/SpecsFor/issues/95#issuecomment-208353841

[ChuckBryan]

Matt - this evening, I am going to cut this project down to the specific areas that are causing problems and, if I still have the issue with that, I'll post it up to BB. Thanks!!!

[ChuckBryan]

Matt:

The signal to noise ratio was bugging me in my app. I didn't want you to wade through that :/

Here is a cut down version that demonstrates the problem that I am having. Hopefully, I am missing something really simple:

https://bitbucket.org/SwampyFox/specsforsample

Chuck

[MattHoneycutt]

Looks like StructureMap's lower-level auto mocker does something funky with AddAllTypesOf under the hood. Try using ConnectImplementationsToTypesClosing instead, like this:

Scan(s =>
            {
                s.AssemblyContainingType<IMediator>();
                s.AssemblyContainingType<MediatorRegistry>();
                s.ConnectImplementationsToTypesClosing((typeof(IRequestHandler<,>)));
                s.ConnectImplementationsToTypesClosing((typeof(INotificationHandler<>)));
                s.ConnectImplementationsToTypesClosing(typeof(IAsyncRequestHandler<,>));
                s.ConnectImplementationsToTypesClosing(typeof(IAsyncNotificationHandler<>));
                s.WithDefaultConventions();
            });

            For<SingleInstanceFactory>().Use<SingleInstanceFactory>(ctx => t => GetInstance(ctx, t));
            For<MultiInstanceFactory>().Use<MultiInstanceFactory>(ctx => t => GetAllInstances(ctx, t));
            For<IMediator>().Use<Mediator>();

Please let me know if that resolves the issue.

[ChuckBryan]

That definitely worked.

[ChuckBryan]

Another follow on observation...

I think I was getting some false/positives on the way that I was checking. I think I was pulling objects off the of Context Map (...or, whatever EF's version of that happens to be). In NH, I might flush it just to force reloads.

One thing that I like to do is to pull my "SaveChange()" into either a filter (or in a Task). When I do that with the integration testing, the changes don't happen because I am testing the controller method directly.

Is there a recommendation, or, an approach to Integration testing that will also fire off filters? I would assume that I would need to capture the ActionResult of the Controller Method and then execute it? I'm not sure if that would fire off the various filters (seems like it should).

[MattHoneycutt]

I've considered adding something to SpecsFor.Helpers.Web to make it easy to run action filters, but I haven't tackled that can of worms yet. You would have to inspect the action being executed, the controller, etc, grab the action filters, and run them in the correct order. It isn't trivial, but it is doable.

I'm going to mark this one as closed. Thanks for providing the repo code. That made it a lot easier to figure out what was going wrong on this one. :)

[ChuckBryan]

My pleasure. I have a few questions over on the NCrunch site about integration testing and localdb (it works, but, after a while it stops because it can't find the DB. After I delete the registration in SQL Object Explorer, it works for a while. I believe I need to name my localdb with a GUID or a ProcessId and manage it that way. I know you mentioned NCrunch before, but not in the context of integration testing. I'd appreciate any words of wisdom!

On Tue, Apr 12, 2016 at 9:37 AM, Matt Honeycutt notifications@github.com wrote:

I've considered adding something to SpecsFor.Helpers.Web to make it easy to run action filters, but I haven't tackled that can of worms yet. You would have to inspect the action being executed, the controller, etc, grab the action filters, and run them in the correct order. It isn't trivial, but it is doable.

I'm going to mark this one as closed. Thanks for providing the repo code. That made it a lot easier to figure out what was going wrong on this one. :)

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/MattHoneycutt/SpecsFor/issues/95#issuecomment-208908940

[MattHoneycutt]

You're on the right path. If you want to use NCrunch in a parallel manner, you'll need to ensure that your DBs are unique across test runs. Be sure you clean them up at the end though. I did this on a project once and didn't have code to remove the DB at the end of a run. Things were fine for a while, until one day I hit the magic maximum number of databases you can have in LocalDB. :)

[ChuckBryan]

Thanks for the some of the valuable clues. I did get this to work. Based on suggestions from Remco (NCrunch), I used the process id instead of a guid to uniquely id my database.mdf and database name. Probably the part that took me longer to noodle through was getting DbContext to use my connection string...I kept overlooking that base call in the "IdentityDbContext."

The easy part was getting specs for to tear it down by creating another behavior.

[MattHoneycutt]

Would you be interested in contributing some code samples and docs about how you got this working to the official docs over at readme.io? :)

On Thu, Apr 14, 2016 at 3:47 PM Chuck Bryan notifications@github.com wrote:

Thanks for the some of the valuable clues. I did get this to work. Based on suggestions from Remco (NCrunch), I used the process id instead of a guid to uniquely id my database.mdf and database name. Probably the part that took me longer to noodle through was getting DbContext to use my connection string...I kept overlooking that base call in the "IdentityDbContext."

The easy part was getting specs for to tear it down by creating another behavior.

— You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub https://github.com/MattHoneycutt/SpecsFor/issues/95#issuecomment-210142568

Matt Honeycutt Pluralsight Author & Senior Web Application Architect [image: Heroic Applications] http://heroicapplications.com/ pluralsight vids http://www.pluralsight.com/author/matt-honeycutt | blog http://trycatchfail.com/ | website http://heroicapplications.com/ | @matthoneycutt http://twitter.com/matthoneycutt

[ChuckBryan]

I may have huzzah huzzahed a bit too early. I should have waited until I had at least two integration specs running to make sure I had all of my ducks in a row. I am getting a "cannot attach the file." Once I get this worked out, I'd definitely like to add this to the docs!

[ChuckBryan]

Matt - here is a little more detail from the above message. I have NCrunch set up to run its test in Parallel. I had some very basic tests that would insert data into the localdb and then get back counts. Sometimes, my test would fail. Sometimes, the counts would be off by one.

Based on recommendations from NCrunch, it was suggested to use the Process Id as the name for the database. When NCrunch is determining which tests needs to run, it'll run those tests in the same process id. Of course, in the SpecsFor world, that would kick off both Given Overrides, which is where I was setting my context for the given tests.

If NCrunch is running different Tests from different Specs, that might not be such a bad thing given that the database is created and migrated once. However, my tests would need to be very specific in what it was trying to query to make sure I am querying/validating the data inserted by the Given.

The other approach would be to generate the database name using a GUID during the Spec Init. I have found this to be a bit challenging because it seems like a lot of Magic happens during the DbContext Constructor. Do you remember how you approached this?

[MattHoneycutt]

I don't have access to the code where this was implemented anymore, but I do remember that we used a Guid for the database name, and that it was effectively one DB per spec. If memory serves, we had a behavior that would generate the DB connection string and all that at spec init, then during spec teardown it would delete the DB.

Without that, yeah, you have state leaking between tests and things won't work well.