[Mono-dev] [PATCH] Fix Roles.IsUserInRole and enhance WebTest Framework

Tiaan Geldenhuys tagdev at gmail.com
Sat Feb 13 03:52:50 EST 2010


Hello Marek:

Since speed then doesn't matter too much in this case, and the
environment-cycling I described as "very slow" really only takes about 5
seconds after all, I would then prefer to stay with the suggested approach
to simply reset the web-test environment after tests that want their own
Web.config files.  So, as per your invitation, I've created the attached
patch with a possible implementation that I hope would now be acceptable.

The patch includes two simple base classes (IsolatedWebHostingPerFixture and
IsolatedWebHostingPerTest, all in the same file at the test just for now)
that cater for the two common starting points of tests where an isolated
web-environment is desired.  Both classes contain the same methods (but with
different default implementations) that one can also override if one needs
an environment somewhere in between these two extremes.  The nice thing
about this approach is that you can stick with the standard NUnit tests in
more test cases (and only use the standalone tests when you really want/have
to).  The tests also don't have to derive from those two new classes, but
they do make it simpler to implement such isolated web-tests.  The new test
named "Enabled" illustrates how one can test the Roles.Enabled property
using three different Web.config files -- I don't think the "meta"
role-provider approach would have worked too well when trying to test all
these scenarios.

Also note in the default Web.mono.config file that I've moved the
"CustomTags" config-section one line down, since it was define in the wrong
place (under the "system.web.extensions" group instead of the root).  It
actually seems like a bug that Mono would not detect this invalid config.  I
would also like to ask if we could perhaps change all the lines that
reference the "System.Web.Extensions" assembly, in the two default
Web.config/Web.mono.config files, from version 1.0.61025.0 to 3.5.0.0 so
that they can be used not only on Mono but also on recent .NET environments
(since I always need to change this for Windows -- however, I haven't tried
it with all the existing tests, but with the ones I have it doesn't seem to
break things for Mono).

Comments or commit?

Regards,
Tiaan.

NOTE: Although the patch files are provided for the 2.6 branch, the four
files that are modified by them can afterward be copied as-is to trunk --
for some reason the patch files for trunk just turned out more clunky,
despite effectively not having to do anything differently.  (I suspect it
has to do with the newline format that is used in the config files.)


-----Original Message-----
From: Marek Habersack [mailto:grendel at twistedcode.net] 
Sent: 11 February 2010 3:50 PM
To: Tiaan Geldenhuys
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] [PATCH] Fix Roles.IsUserInRole and enhance WebTest
Framework

On Thu, 11 Feb 2010 11:58:53 -0600
"Tiaan Geldenhuys" <tagdev at gmail.com> wrote:

> Hi Marek:
Hey,

> 
> Thanks for committing almost all the changes, especially the ones to
> WebTest.  However, I would still like to get some ideas about a better way
> to then isolate the Web.config settings between different Tests and Test
That's why I created support for standalone tests - see
System.Web/Test/standalone* in trunk

> Fixtures -- because that seems to be the main issue with the changes that
> weren't approved, and having one RoleProvider configuration that must be
> shared between all tests is not really an option.
The test suite doesn't like being restarted (which happens if you update
Web.config, bin/*, App_*
etc) and I have no time to spend fixing it atm.

> One approach could be to call WebTest.SetupHosting with a delegate that
> calls CopyResources to start with the default Web.config and then perhaps
> add the roleManager section programmatically in the setup delegate
(instead
I really see no reason for this. You can provide an implementation of a
"meta" role provider which
will dispatch the calls to the specific role provider you need in a
particular test - that way you
have only one role provider in the web.config. Or you can access the
Roles.Providers collection
directly to get any named provider you defined in web.config

> of overwriting the config file completely, like I did previously; and
> instead of always having the same RoleManager, like you now did, which
could
> also interfere with other test that assume the default of not having any
I know this is not ideal, but with the way the current test suite works this
is the best we can get
(or we can just create more standalone tests, which for this kind of test is
the best option anyway)

> role manager, or at least with tests I would still like to contribute).
If
> isolation between tests is important, then one could add tear-down logic
to
> the test that could perhaps call WebTest.CleanApp (so that the next call
to
> EnsureHosting would start from fresh).  The problem with this approach is
Yes, this is a solution but as said above - I don't have time to spend on
this right now. Patches
are welcome, of course :)

> that it seems to be very slow, and perhaps that's why the tests currently
> have to share their config.
Speed doesn't matter in this case.
 
> Ideally one would want to re-use any existing host and simply add/remove
> settings to Web.config programmatically in the test's start-up/tear-down
> logic (after calling WebTest.EnsureHosting).  But for this to work,
> WebTest.Run should only execute the next test after the updated Web.config
> has been loaded -- I've quickly tried this previously and ran into race
> conditions.  Do you know of a way that this synchronization can be added
to
> WebTest without too much trouble?
I haven't spent any time on this, but I imagine it shouldn't be too
complicated.

best regards,

marek
> 
> Regards,
> Tiaan.
> 
> 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RolesTest_branch-2-6.patch
Type: application/octet-stream
Size: 7656 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100213/fdadb6ed/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Roles_branch-2-6.patch
Type: application/octet-stream
Size: 590 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100213/fdadb6ed/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Config_branch-2-6.patch
Type: application/octet-stream
Size: 2128 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100213/fdadb6ed/attachment-0005.obj 


More information about the Mono-devel-list mailing list