1

So I'm running into an interesting problem trying to get Selenium to work well.

Originally I had this setup:

  • CassiniDev starting up as part of my test suite
  • External Selenium grid connecting to the CassiniDev instance for testing the software.

The benefits to this approach over IIS Express are:

  • CassiniDev allows external connections without complicated trickery, meaning the grid can easily connect.
  • Using the grid allows me to use more computers, and different platforms easily.
  • Using CassiniDev gets me code coverage out of the box (some solutions can get me code coverage on IIS for money, but code coverage is the least of my problems switching to IIS right now).

However I recently added OWIN to this project and OWIN cannot run with CassiniDev due to needing an integrated IIS pipeline to work correctly (see "This operation requires IIS integrated pipeline mode."), this leaves me two options:

  • Use IIS Express, lose code coverage, lose the grid, lose the multi-platofrm testing, complicate startup/shutdown, development machines would have to have Selenium installed to run tests locally, build agents need Selenium installed.
  • Use full blown IIS, lose code coverage, keep the grid, keep multi-platform, complicate testing heavily (coordinate IIS deploy), build agents need full IIS installed and any dependencies, development machines that want to run Selenium need IIS installed.
  • Publish the application to an IIS server for testing, no local testing for development, no parallel lines of testing (unless we have a complicated publish setup).
  • Throw Selenium tests in the garbage.
  • Look into OWIN self-hosting (site includes webforms stuff so I don't think I can self-host, nor am I sure how much this is compatible for when I do deploy to IIS)
  • Disable OWIN when testing (limits my ability to actually use OWIN to side-modules though or systems I don't test)

All of these solutions seem poor at best, losing out on all the benefits I had with CassiniDev. Any other options/ideas?

Community
  • 1
  • 1
StrangeWill
  • 2,078
  • 1
  • 21
  • 35
  • Back when we switched from 32-bit to 64-bit CassiniDev didn't work (without an unofficial rebuild) on 64-bit so we switched to IIS on our dev machines. We really haven't looked back since. It may be a bit of extra work to require IIS on your dev machines, but I think it's worth it in the long run for consistency between test and production. I would think for your own modules, you'd even be able to keep code coverage by debugging IIS out-of-process? I'm not sure what your deployment scenario is though, ours is just copying a few files to the right place. – ebyrob Feb 13 '17 at 14:58
  • Deployment is Octopus Deploy so not a huge deal, not sure how I'd debug IIS out of process from the command line of TeamCity or from within XUnit driven Selenium tests... I guess I could configure a default IIS directory and have build agents clean the directory then deploy the application to that directory, not sure if that'll be a logistical nightmare though. – StrangeWill Feb 13 '17 at 23:59

0 Answers0