Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

This question has been revolving on my mind from quite some time. Do you develop one method for one test scenario or club similar scenarios in one method and develop automated tests for it. Both approaches have their pros and cons. For example consider you are writing GUI level automated tests and are validating whether application has certain elements on page or not, and if it succeeds then you proceed with more tests now do you do something like this -

testGUIElements() {

Assert Element1;
Assert Element2;
Assert Element3;

}

or do you do something like -

testElement1() {
}

testElement2() {
}

testElement3() {
}

I am not writing my approach here to avoid getting biased answers... I must mention that I am not a developer and has been hard core manual QA in my career.

n.b. I modified the question to make it more clear, hopefully :)

share|improve this question
    
Tarun - I realise you don't want to put your approach in, but it's a bit hard to figure out what your question is here! I'm always interested in test design questions, but I can't figure out what you're trying to ask here - can you add a bit more detail? –  testerab May 29 '11 at 13:25
    
I agree, this question is very hard to answer –  Bruce McLeod May 29 '11 at 14:00
    
Hey, what is that book? –  Tarun May 29 '11 at 17:29
    
I think @glowcoder is referring to How We Test Software at Microsoft - but it doesn't answer this question (but I'll try below) –  Alan May 29 '11 at 17:55
1  
thanks for editing, much clearer now! –  testerab May 29 '11 at 20:41
add comment

4 Answers

up vote 5 down vote accepted

My preference is to have one test per element. This aids in diagnosability (test failure points directly to missing element) and maintainability (e.g. if elements are added or removed). I also like to use namespaces and classes to group the tests - e.g.

namespace TestPrerequisites
{

   public class GuiElements
   {
      public bool VerifyElementOne() {...}
      public bool VerifyElementTwo() {...}
   }
   //you could put other prequisites in this namespace
   public class DatabaseElements {}

 }
 namespace FunctionalTests
 {
    // put functional tests here - 
    // note that you could group these by type of tests, 
    // or functional area as appropriate
    // (e.g. "namespace InputTests"
 }
share|improve this answer
    
The problem I see with this approach is lots lots of coding. So I could put all these elements in one file, read them from my test script and validate. Now if any of element is missing from application then I would throw one exception at the end of test with appropriate message which says what failed where. I happened to write a blog post on this approach of late. As always, thanks for sharing your views +1 –  Tarun May 30 '11 at 4:44
    
This approach works best in an editor that has something like Intellisense in Visual Studio. –  Alan May 30 '11 at 14:35
    
Alan, I guess you are trying to say that having exclusive verification points for each elements will be easy with IDE like Visual Studio, are you? –  Tarun May 30 '11 at 17:38
    
@Tarun - I'm saying it's "easier" - nothing is easy :} –  Alan May 30 '11 at 20:22
add comment

If the test methods are repeatedly used in other tests and can be made reusable you could define it as a separate method. For example Login method is used by almost all the test cases. Creating a separate login test method enhances re-usability and avoids writing code from scratch each time.

For testing login method the test method should be separate and re-usable as below:
testLogin()

If you are defining a specific scenario that is seldom re-usable you can group up the verification points in a single method. Alan's suggestion is valuable in this case. Define a package say payment for all payment related testcases. Define a class for each payment test case say testShoppingPay, testRecurringPay. Inside each class you need to call a reusable method for initial setup. Write a testmethod for verification points involved.

It would look like:
testinitSetup() //Method for initial test case setup

test() //contains all verification points
{
testLogin() //Calls reusable login method
Assert(Element1Present)
Assert(Element2Present)
......
......
}

share|improve this answer
3  
You may also want to consider what happens when an assertion fails. For example, in Watir (and Selenium I think), a failed assertion will end the test and move on to the next one. If you use verify, it will log the failure and continue on. I prefer to use verify if I'm grouping multiple checks into one test case that may fail independently of each other (ex. UI verifications). –  marc May 29 '11 at 21:03
    
+1 Good point, Exactly! Assert will stop the execution of the test case if the verification point fails while verify continues. When multiple checks are used it is better to go for verify. –  Aruna May 29 '11 at 22:19
    
@marc Selenium does not dictate what happens when an assertion fails; that is up to the framework. You if you use Selenium with JUnit, you will get the semantics you described. Of course you don't have to use JUnit in order to use Selenium. –  user246 May 30 '11 at 13:16
    
@marc, this is exactly what I do –  Tarun May 31 '11 at 3:50
add comment

This is IMHO a good reason to use a framework such as Cucumber that allows you to have steps that are reusable between multiple scenarios, and also provides ways for a scenario step to repeated multiple times with different data, or an entire scenario to be repeated with different data.

share|improve this answer
add comment

My preference would be one method per test scenario

Reasons

1.Easy(ier) to cherry pick and port/maintain/change/execute/analyze

2.Better traceability -- 1:1 relationship between test scenario & test method

share|improve this answer
    
+1 at the end of the day developers need to reproduce the bug, when I tried combinations of tests in order to reduce the number of total test cases (actually this applies to testing in general, not just functions testing) I got a lot of complaints from developers. –  Rsf May 30 '11 at 6:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.