Help - How do you organize your Test Methods in Selenium?

Hi,

I am using Selenium with TestNG for my test automation framework. I’m struggling to organize my @Test methods in my Test classes. P.S. I am using Page Object Model.

My question is: Let’s say I’m in CreateUserPageTests class, and there I would have to fill up few mandatory fields to complete my test. Example: Name, Address Phone No.

Now how do you write your test methods here. For every field there is a separate test method with assertion?

public class CreateUserPageTests extends BaseTest {
CreateUserPage createUserPage;

@Test(priority = 1)
    public void testSetName()  {
        createUserPage = new CreateUserPage(getDriver());

        assertTrue(createUserPage.setTxtName("Test Bro"));
}

@Test(priority = 2)
    public void testSetAddress()  {
               assertTrue(createUserPage.setTxtAdress("Test address"));
}

@Test(priority = 3)
    public void testSetPhoneNo()  {
                assertTrue(createUserPage.setTxtPhone("123"));
}
}

or do you fill-up the complete thing in a single Test method?

public class CreateUserPageTests extends BaseTest {
CreateUserPage createUserPage
@Test(priority = 1)
    public void testCreateUser()  {
        createUserPage = new CreateUserPage(getDriver());

        assertTrue(createUserPage.setTxtName("Test Bro"));
       assertTrue(createUserPage.setTxtAddress("Test Address"));
       assertTrue(createUserPage.setTxtPhoneNo("0123"));
}
}
1 Like

I would say it is up to you and to your situation. There will be people that prefer option 1 or option 2 or … there are those that say that assertions should be in the PageObject and not in the test.
I cannot give you an answer but what I can recommend is to have a look at the original Page Object article PageObject and at this one that discusses about the different approaches to structure/do Page Objects Going Deeper into the Page Object Model | by Blake Norrish | Jul, 2022 | Medium

3 Likes

Hi, and thanks for the great question. I love to use “it depends”, but like @restertest who does this far more than I do, I have to agree. I was also just about to dig out those exact same web links. I’ve not got that much web app experience , but this is my opinion.

It’s far too easy to overthink test automation in the beginning, but it’s also easy to work in a messy fashion. I’m using Appium on top of Selenium, but I’ve also used Selenium directly, and I totally go for Page objects. But when your start out you might be thinking more “workflows” and page objects might be too much “boilerplating” and lifting work. That’s OK to think that way. I would go as far as possible until you start hitting code-reuse frustration, before writing any page objects. You will have plenty enough other pain to not be debugging your page objects. Especially since many page objects will look too similar or sometimes just be a transition, don’t need to be fully “populated” object with all the controls defined in the classes. So you will sometimes hit situations where you think a page is actually multiple “pages”, but the user might just think of it as a wizard, like when you enter a username, then the password field only appears afterwards, and then afterwards an CAPTCHA field appears depending on some other condition like, what their IP address happens to be. Those all feel like one page. But they might not be easy to code as one object. Dont be scared to split a page-object into multiple classes when needed.

To make things easier, make sure that you allow your page objects to be composable or inheritable, so that you can extend or build out as you go. One hint I used for deciding if a thing is multiple objects that maybe inherit from each other or not, is if the URL is different for each page. If it’s possible to navigate the prover to that particular state using a URL (but not using parameters), and the base url is the same, then it’s probably one page. Whatever you do, decide on a rule and stick to it. Then, take all common “functionality” or generalized helpers in a page and put them into a base class, and rebase all objects from that class.
Then add some debug helpers to that class to log out more detail when things fail, and add some helpers for specific kinds of controls that give you pain. Finally those “helpers” for controls like treeviews, passwords, drop-lists and so on will become classes themselves. So plan for things to keep evolving. Because towards the end of the journey , if you decide page object if for you, you will will have a completely separate module with just the page object code. At this point you can have multiple testers work together at the same time on other tests, without breaking things , because page objects by design are loose-coupled. Your initial page-objects won’t be, but don’t worry, it’s an iterative process. Plan for the long ride, but start with short trips that add value.

2 Likes

Thank you for replying. I will definitely go through the resources you provided.

Appreciate you taking the time to write in detail. It was insightful. Thanks a lot.

1 Like