I did want to touch on this because the C# ecosystem does have a lot of
things that solve this problem.
It seems like this is probably more a cause for dependency injection and
something like NSubstitute, which allows you to mock out any interface
really easily. The danger of using a real IIS system is you're using a real
IIS system, which means you're coupled tightly to the behaviors and nuances
that has. Plus you're testing more than is necessary to proof the concept -
really, you just need something to come back with a canned response. If
it's in C++ you could use Google Mock or Hippo Mock, but both are way more
verbose than NSubstitute.
They describe it really well here: http://nsubstitute.github.io/
But the thought I was having is you could test pretty easily using
Dependency Injection and having the class take an instance of, like,
IHttpWebController or something. Let's say this interface looked like:
interface IHttpWebRequest
{
ResponsePacket SendRequest(HttpRequestPacket packet);
}
NSubstitute can easily fake this interface similar to like:
var sub = Substitute.For<IHttpWebController>()
sub.SendRequest(Arg.Any<>()).Returns(new ResponsePacket { set properties
here });
Then you could simply change the Bundle class to accept an
IHttpWebController and viola - you have a totally segregated connection to
the web where your unit tests aren't trying to hit web addresses that may
or may not work. I haven't looked in to how the Bundle is manipulating
HTTP, but it does seem to be that we would want this is as decoupled as
possible. E.g. there's no real reason that someone couldn't want to develop
MSI For Mac or something and WiX would be the obvious central piece of that.
Honestly, I've found that it's almost always easier to work through this
approach of testing versus trying to spell it all out in detail once you
get used to it. It also avoids connection issues and other weird behaviors
like some computers randomly not being able to run unit tests, etc.
Once you start getting in to DI, it becomes almost automatic that you are
looking for some type of component service provider. That's when you get in
to stuff like AutoFac, which can seriously make life way easier for the
production side application and causes almost an irrelevant performance
change: http://autofac.org/ My personal opinion is that unit tests should
never take more than a couple of seconds - starting up IIS Express on my
computer alone can take 5 or 6. Plus the tests allow you to test things
that a unit test really can't get; e.g. 500 errors, 302/301/300, 405 black
holes, etc. In theory those things should "Just work" but it's good to know
that those error states are covered sometimes (especially 301/302, which
web servers like to abuse the heck out of in my experience).
On Tue, Jul 15, 2014 at 2:22 PM, Rob Mensching <r...@firegiant.com> wrote:
> I use IIS Express. A bit of a pain to configure but comes with VS and
> mimics IIS very well (since it is mostly IIS <smile/>).
>
> _______________________________________________________________
> FireGiant | Dedicated support for the WiX toolset |
> http://www.firegiant.com/
>
> -----Original Message-----
> From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
> Sent: Tuesday, July 15, 2014 11:22 AM
> To: WiX toolset developer mailing list
> Subject: Re: [WiX-devs] Self Updating bundles and test cases
>
> One suggestion I got from a co-worker was Nancy,
> http://www.nuget.org/packages/Nancy.
>
> -----Original Message-----
> From: Phill Hogland [mailto:phogl...@rimage.com]
> Sent: Tuesday, July 15, 2014 1:14 PM
> To: wix-devs@lists.sourceforge.net
> Subject: Re: [WiX-devs] Self Updating bundles and test cases
>
> source is available on GitHub
> https://github.com/cesanta/mongoose
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Self-Updating-bundles-and-test-cases-tp7595852p7595856.html
> Sent from the wix-devs mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck Code
> Sight - the same software that powers the world's largest code search on
> Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck Code
> Sight - the same software that powers the world's largest code search on
> Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
