This is a tricky problem because it all comes down to deciding what's common
and what's not. Or, equivalently establishing the Context for a test.
Obviously there are a lot of combinations. User is logged in, user is
logged out, user of a different type is logged in, different browser, coming
from a partner site, time of day, phase of moon, current weather forecast,
err...
What I like to do is to first step away from the performance issue. UI
tests are slow so first inclination is to try to avoid logging in twice,
etc. The combinatorial approach is slow, but not all combinations are
really relevant.
I think it's more useful to just encode the scenarios we care about in an
efficient and maintainable manner.
Less vague. Let's say we're writing a WatiN based web test. First we take
care of the basics and factor out as much of the structure of the
application as we can. We can use Page objects, helper classes of various
sorts, and other things as needed.
[Test]
public void DoStuff()
{
var loginPage = Browser.Page<LoginPage>();
loginPage.GoTo();
loginPage.LoginWithCredentials("hacker", "letmein");
var mainPage = Browser.Page<MainPage>();
mainPage.ClickOnProduct("X");
var productPage = Browser.Page<ProductPage>();
Assert.AreEqual("$5.00", productPage.GetProductPrice());
}
In principal, we can factor out much of the common stuff. At the end we
have a few pieces left for each scenario we need to run.
Some tools like combinatorial tests, test factories, and data driven tests
can help... but you know, that's a lot of machinery and it's not always
needed. The clever machinery breaks down when you find yourself wanting to
filter out certain cases or treat them just a little differently.
It may feel repetitive but directly encoding the test matrix can work out
quite well. Cut out code duplication where possible but there are limits to
what's practical.
Jeff.
On Fri, Mar 18, 2011 at 5:50 AM, Sedat Kapanoglu <[email protected]> wrote:
> We're currently using MBUnit for both unit testing and UI testing. For UI
> testing setup cost for test matrix axes are pretty high (login, browser
> instance, navigate to page etc). In order to avoid setting up these for each
> test case we are partly relying on AssemblyFixture to manage some of them.
>
> However since it's not possible to filter out certain cases where they are
> not applicable to certain combination, it's not possible for us to really
> use such optimization. So currently we are doing some of the setup per
> test-case, horribly inefficient.
>
> We could put if statements inside test code to check for correct
> combinations but we don't desire that either. It pollutes test code.
>
> How do you guys do such optimizations? or test matrix management? Is there
> a better practice?
>
> Thanks,
>
> Sedat
>
> --
> 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.
>
--
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.
