search

skaliber / mb-unit

Automatically exported from code.google.com/p/mb-unit
0 stars 0 forks source link

Support running tests within an ASP.Net hosting context. #96

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
Support running tests within an ASP.Net hosting context.  This is useful
when you can't mock or stub out dependencies on System.Web types such as
HttpContext and HttpApplication.

Could be implemented as a custom MbUnit attribute.

Original issue reported on code.google.com by jeff.br...@gmail.com on 9 Nov 2007 at 9:33

GoogleCodeExporter commented 8 years ago 
No, not as an attribute.

Do this as a test domain like the IsolatedProcessHost.  This would be most 
effective
when combined with the option of having test assembly config files.  The config 
file
could state that the given runner or ITestDomain (such as an ASPNetTestDomain) 
was to
be used and configured in such and such a fashion.

There are some tricky problems here involving the layering of hosts and test 
domains
since there are multiple cross-cutting concerns involved in hosting.

For example, how should an IsolatedProcessHost be combined with something like 
an
ASPNet AppDomain?

Original comment by jeff.br...@gmail.com on 17 Mar 2008 at 11:16

GoogleCodeExporter commented 8 years ago 
Here's another use-case from Stephen Bohlen.

=====

I think the general idea = excellent~!

It sounds to me like this might very well solve my issue.  Instead of the 
approaches
that I (and others) have listed in theses posts here where the test-runner 
actually
launches a new process within which to host its tests, I would guess that for 
the
ASP.NET scenario you are suggesting the test-runner would likely actually 
attach to
an existing process for running its tests.

This approach would certainly (at least possibly) support my scenario since I 
could
just as easily already have the ACAD.EXE process running before the test-run 
started.
 As I am imagining this feature, I would specify something in my
testassembly.dll.config that would specify that the test-runner should first 
attach
to some running process and THEN start running its tests on the test assembly 
under
that process.

Sounds like an excellent approach (and also a really interesting idea re: the 
ASP.NET
scenario since it would seemingly allow someone to unit-test their WebForms apps
without the attendant challenges of having to mock previously-unmockable 
HttpContext,
etc.).

I can't wait -- but will have to, of course :D

My feedback = sounds like a great idea both for my scenario and for others.

-Steve B.

--- In altdotnet@yahoogroups.com, "Jeff Brown" <jeff.brown@...>
wrote:
>
> MbUnit v3 will support something of this sort for running tests
inside of a
> host of your choice.
> The initial target use-case is for running tests inside of
ASP.Net, but it's
> quite possible you could shoehorn your host application into this
model as
> well.
> 
> In order to use this feature, you would provide a test assembly 
> configuration file with some specifics about how the test assembly
should be
> hosted.
> 
> This functionality is not yet implemented.  But am very interested
in any
> feedback about the general idea.
> 
> Jeff. 
> 
> -----Original Message-----
> From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com]
On Behalf
> Of stephen.bohlen
> Sent: Wednesday, April 09, 2008 4:53 PM
> To: altdotnet@yahoogroups.com
> Subject: [altdotnet] Unit Testing code that requires an external
program
> 
> I have an application (compiled as a .NET dll) that runs as an add-
 in to
> another application (the host app).
> 
> As anyone would do, for debugging it during development I have set
Project
> Properties --> Debug --> Start Action to 'Start External Program' 
and then
> provided the path to the host application's .exe so that when I
invoke the
> debugger from the IDE it properly spawns the host app and I can
properly
> debug my own code.  Nothing at all unusual in any of that.
> 
> But now I want to write unit tests against my code and need to
somehow find
> a way to spawn the host app during the test-runner's execution of
my unit
> tests.  Without the host app running and hosting my own assembly,
I cannot
> even instantiate any of my own objects that depend on this host
app's
> presence during my unit test- runs.
> 
> Sadly, the really great and (seemingly) obvious solution to this
issue
> doesn't work at all: setting the unit test project's Debug -->
Start Action
> to the same .exe of my host app that my actual project uses to
support
> debugging.  Was worth a try, at least, but no-joy.
> 
> Does anyone have any other ideas how to get the unit test runner
to spawn my
> host app as a host process for the code-under-test?  I am using
MbUnit 2.4.x
> with the ever-excellent TestDriven.NET as my test- runner but
would be
> willing to step back and use the MbUnit test runner for these
kinds of tests
> if anyone has any ideas that would involve me switching to a
different
> test-runner than TestDriven.NET.
> 
> Before everyone jumps all over me with comments like 'SoC means
you need to
> develop your classes such that they don't depend on the host app
in order to
> run and thus you can test them in isolation', thank you very much
for the
> obvious but the public methods that I need to test are meaningless
outside
> of the context of the host app (and not possible to abstract away
to
> non-host-app-dependent).
> 
> I realize that in some sense this is more of a sort of integration-
 testing
> challenge vs. a unit-testing challenge but no matter the name of
the tests
> I'm trying to run, does anyone have any ideas about how I could
achieve this
> (spawn other process to 'host' my unit tests when invoked')?
> 
> FWIW, the host-app in the above context is AutoCAD 2008, if that
helps in
> piquing anyone's interest.
> 
> Thanks in advance for any input/suggestions,
> 
> -Steve B.

Original comment by jeff.br...@gmail.com on 10 Apr 2008 at 10:44

GoogleCodeExporter commented 8 years ago 
SQL Server is another possible use-case.

Original comment by jeff.br...@gmail.com on 11 Apr 2008 at 12:40

GoogleCodeExporter commented 8 years ago

Original comment by jeff.br...@gmail.com on 19 Nov 2008 at 11:58