CassiniDev self hosted MVC

Sep 14, 2010 at 3:25 PM
Edited Sep 14, 2010 at 4:01 PM

I wanted to wrap some integration tests around an MVC site I'm starting.

If I have the V.S. cassini running in the background and point my tests at that URL I can get my tests to work. However when I try to use the CassiniDev assembly to start up a server (similar to this http://cassinidev.codeplex.com/wikipage?title=Using%20CassiniDev%20with%20unit%20testing%20frameworks%20and%20continuous%20integration&referringTitle=Documentation) and point my tests to that location. I keep receiving 404 errors.

Have you or others used this with Asp.Net MVC? Any tips that I might get to make this work?

Update:
It appears that it's working with CassiniDev (the GUI version). - but I'm still struggling with the referenced assembly. 

Sep 14, 2010 at 4:09 PM

Nevermind... I had a strange case where, after moving my MVC site from one directory to another one TFS left the old directory name behind on disk, but moved everything else. So my the site being used in my test project was pointing to an empty folder... Sorry for any inconveniences.

 

Coordinator
Sep 18, 2010 at 8:27 AM

No worries.

Glad to hear it is working out for you. If you do run into any issues while integration testing your MVC apps, be sure to add another post as I am about to embark on an MVC integration test adventure for the first time.

Sep 27, 2010 at 10:56 PM

I am actually having this issue and am happy that I'm not attempting a StartServer with an empty path.

I'm running ASP.NET MVC 2 on framework version 4 and referencing the CassiniDev4-lib.dll.

The site launches and responds fine when using CassiniDev4.exe but when I launch in-process it doesn't respond.

Using Selenium RC to access a resource gives me a 404. Hitting a breakpoint after starting and then attempting to browse to a valid url, even the root, just times out.

I'm a bit perplexed and would appreciate any guidance on debugging this.

Sep 27, 2010 at 11:31 PM

Further testing has revealed that it will serve a static html file to Selenium RC and when I browse manually while the code is paused on a breakpoint so it would appear to be an MVC routing issue.

Coordinator
Sep 27, 2010 at 11:38 PM

I will give this some attention this week. Thanks for the bug.

Sep 28, 2010 at 11:37 AM

Thanks Sky. Please let me know if there is anything I can do to assist the process.

Coordinator
Sep 28, 2010 at 11:33 PM

Adam, if you could give me specifics as to your setup so that I can repro.

i.e. are you using a fixture that starts the server, if so what test framework  etc

 

Sep 29, 2010 at 9:50 PM

Sky, I've setup a test project just to remove as much noise as possible and discovered that the issue appears to be use of the [HttpGet] on a controller action. Without the attribute, the page responds, with the attribute it times out / throws 404 in Selenium. I can post a link to the project if it would be useful.

NUnit 2.5.5, Selenium RC 1.0.1, .Net Framework 4, ASP.NET MVC 2

Coordinator
Sep 29, 2010 at 9:56 PM

I would like to find out where the problem lies, so yes, a link would be great.

Sep 29, 2010 at 10:02 PM

Project can be found here: http://dl.dropbox.com/u/1542135/CassiniSpike.zip

As you can see from the single test method in the test project, I'm testing the Logon action of the Account controller. Adding or removing the HttpGet attribute toggles the behaviour. The project itself was just the standard MVC2 project template.

Please let me know if anything isn't clear.

Adam

Coordinator
Sep 29, 2010 at 11:08 PM

Selenium appears to be sending a HEAD request instead of a GET which explains why you are getting 404 when you restrict the action to HttpGet.

To confirm, place a breakpoint in Logon() and examine the Method property of the Request.

This appears to be an incompatibility between selenium and MVC.

CassiniDev appears to behave as expected.

Please confirm and report back what steps you take to configure Selenium to send a GET instead of HEAD as this will likely be of interest to others as well.

 

Also, I would suggest removing the .StopServer() in the teardown. I mistakenly left that in for the .lib fixture examples.

It is only relevant to out-of-proc cassinidev.exe.  

This will eliminate spurious exceptions that you may have to pass through at the end of a debugging run.



Coordinator
Sep 29, 2010 at 11:33 PM

Selenium Head before Get is a known issue:

see 

http://code.google.com/p/selenium/issues/detail?id=462

http://groups.google.com/group/selenium-users/browse_thread/thread/a72e4df5a2fc8d7d

Coordinator
Sep 29, 2010 at 11:36 PM

see workaround at the bottom of this post: http://groups.google.com/group/selenium-users/browse_thread/thread/a72e4df5a2fc8d7d

 

Basically says to add a param to the Open call to prevent the HEAD request.

Sep 30, 2010 at 3:09 PM

Thanks for your research on this Sky, above and beyond.

I'm also testing WatiN (http://watin.sourceforge.net/) for intergration testing and this seems to working and has the added benefit of not having to run and manage a seperate server to coordinate the requests.