Thanks.. Yes, I'm concerned too :-)

I've been using .NET Memory Profiler to try and track down the causes.

These tests are database integration tests using Castle and
NHibernate. It seems that each test that runs leaks, which I suspect
is due to some of the dynamic (proxy) classes that these libraries
create. Even calling Dispose() on the container doesn't release
everything, as I think these are stuck in the appdomain.

These are integration tests, so we expect that they'll run slower, so
that isn't such an issue.

-dave

On Dec 16, 7:53 am, Jeff Brown <[email protected]> wrote:
> Unfortunately this is not supported out of the box right now.  I do have
> some refactoring in mind that will make it possible but I can't promise when
> that will be done.
>
> I'm concerned about the tests running out of memory.  Loading up extra
> AppDomains will increase the memory pressure somewhat and may also
> significantly slow down test execution.  If there's a big leak in the 3rd
> party libraries you are using then it could affect you in production too.
>
> I'd recommend using a memory profiler like DotTrace to help pin down the
> cause.  Once you've got that figured out, it's unlikely you'll need to
> resort to exotic fixture isolation strategies anyways.  :-)
>
> Jeff.
>
> On Mon, Dec 14, 2009 at 10:38 PM, David Gardiner <[email protected]>wrote:
>
> > I know that you can run the entire assembly in a separate process or
> > appdomain using the /runner parameter, but is is possible (or
> > relatively easy) to specify that just a particular test or a test
> > fixture be run in a separate appdomain?
>
> > I have some tests that seem to generate a lot of memory allocation
> > (apparently from 3rd-party libraries), to the extent that sometimes
> > the tests don't complete because they run out of memory.
>
> > If I could load each fixture into a separate appdomain, then I suspect
> > the memory issues would be reduced.
>
> > -dave
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "MbUnit.User" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<mbunituser%[email protected]>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/mbunituser?hl=en.
>
>

--

You received this message because you are subscribed to the Google Groups 
"MbUnit.User" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/mbunituser?hl=en.


Reply via email to