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 :)

  • 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, 2011 at 13:25
  • I agree, this question is very hard to answer May 29, 2011 at 14:00
  • Hey, what is that book?
    – Tarun
    May 29, 2011 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, 2011 at 17:55

4 Answers 4


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"
  • 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, 2011 at 4:44
  • This approach works best in an editor that has something like Intellisense in Visual Studio.
    – Alan
    May 30, 2011 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, 2011 at 17:38
  • @Tarun - I'm saying it's "easier" - nothing is easy :}
    – Alan
    May 30, 2011 at 20:22

My preference would be one method per test scenario


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

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

  • +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, 2011 at 6:13

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.


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:


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<br>

test() //contains all verification points<br>
      testLogin() //Calls reusable login method<br>
  • 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, 2011 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, 2011 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, 2011 at 13:16
  • @marc, this is exactly what I do
    – Tarun
    May 31, 2011 at 3:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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