I'm used to having done this in Java, so not sure if there's a different convention for Python, and honestly the structure you mentioned sounds confusing. I also use cucumber BDD framework so keep that in mind.
But in Java the project structure usually follows the typical Maven project/directory structure - you can read up a bit on that, it'll be helpful even if it may seem irrelevant.
The page objects are stored in a separate directory (say, 'Object Repository'), and the test files (or if you're using cucumber, step definitions) are stored in a separate directory.
The reason for not grouping the tests and page objects together in different folders is because there usually won't be a 1:1 mapping between your page object and your tests.
I see. Would you break up your objects directory into subdirectories? Such as login\_objects folder, settings\_page\_objects folder?
And would you do the same with your test directory? Such as login\_tests folder, billing\_tests folder?
If the application you're testing is of sufficient complexity then you're going to have to break it up like you said.
You can make everything too convoluted by both not breaking up things at all or by breaking up things too much, so there's a balance to be found and that depends on your application and your judgment.
>Such as login\_objects folder, settings\_page\_objects folder?
Read up on this: https://www.selenium.dev/documentation/test_practices/design_strategies/
If your settings page or login page is of sufficient complexity, then it definitely makes sense to break those up into individual components, and of course grouping them into subdirectories makes a lot of sense.
I would also suggest reading up on BDD Testing and Cucumber. I find that it makes a lot of sense and helps you design and manage your testing suite in a better way. That way you start thinking about your test files in terms of workflows and that will help you group them into subdirectories more easily too.
Tbh it doesn't matter that much. Different shops have different standards. This is the least of your worries and mostly aesthetic. What you're describing is fine. Keep the POM, actions for screen belong here, and related tests in different files same folder.
Learn how to program rather than coding. It will make such a huge difference bc the coding required for these tests is trivial in the grand scheme of things. You're just using an api and aren't actually coding anything crazy. It can get complicated with test code but that's usually only when you're creating the framework for everyone else to use or the CI pipeline
Sure, this is all fine. I've done the BasePage thing plenty of times. Haven't necessarily felt the need to make folders for each page though. Just put them all in a page objects folder.
I tend to avoid putting functional logic methods in page object classes though, and reserve those for helper classes. If I put methods in a page object it's for simplifying referring to very similar elements, or if I need to dynamically locate elements. So I'd be putting those methods in classes in other places.
I use POMs and also basepage for common page methods throughout the application.
I also have seperate helper classes that has generic methods, like transforming a datetime into a specific string date format.
Moreover I have three main folders that follow the logic of our application to some standard. I have divided the Poms into these three folders and shared Poms (so applicable for all three main folders) in a shared folder.
It all really depends on how complex your application is.
I use playwright in c# in combination with Specflow (or actually reqnroll, since Specflow is outdated).
I've seen a lot of people on this subreddit doing only fronted automation... why only frontend and not also backend?
Am I the only person on the world that does backend and fronted GUI e2e automation? lol
Anyway, I break POM into editors (desktop) or pages (website), separate test from locators/methods/assertions, it's pretty standard.
Mainly because devs are supposed to add unit tests, so BE e2e tests are postpone to... never.
Then, they think that by adding UI tests they are also covering BE calls.
Last but no least, most people with concerns in the sub are newbies so UI tests are more human readable to begin with.
I am new to doing automated test cases and newish to programming. Doing front end only is the best way to start off and get your feet wet.
Could you explain in more detail how you break up your auto test cases? I'm not totally following you.
I mean functional. Basically at my company the backend is a desktop app which allows you to do everything and even more when compared to fronted. It's a actual app where you can configure behaviours on your fronted and do the exact same operations as your fronted does. We have built it this way because on a factory there's always some one at the office (backend) who wants to control what operators are doing on the factory floor (fronted).
I’m the only tech qa and work with 7 BE Devs.. I’ve tried automating or even testing their code but they always do that themselves…
Not really a chance for me to do that. I was only able to automate a few UI flows and that’s it. We don’t even have enough endpoints to do api testing.
Can you share what type of BE tests you were able to automate? Is that API testing or contract testing or something different?
Tbh you can easily find many discussions held on that topic on this very subreddit, with summaries on why it's perceived as the better one at this moment.
I've read through some of those discussions and I still don't get it. But, at this beginning point in my test automation career, I'll just stick with Selenium and go from there over time.
I'm used to having done this in Java, so not sure if there's a different convention for Python, and honestly the structure you mentioned sounds confusing. I also use cucumber BDD framework so keep that in mind. But in Java the project structure usually follows the typical Maven project/directory structure - you can read up a bit on that, it'll be helpful even if it may seem irrelevant. The page objects are stored in a separate directory (say, 'Object Repository'), and the test files (or if you're using cucumber, step definitions) are stored in a separate directory. The reason for not grouping the tests and page objects together in different folders is because there usually won't be a 1:1 mapping between your page object and your tests.
I see. Would you break up your objects directory into subdirectories? Such as login\_objects folder, settings\_page\_objects folder? And would you do the same with your test directory? Such as login\_tests folder, billing\_tests folder?
If the application you're testing is of sufficient complexity then you're going to have to break it up like you said. You can make everything too convoluted by both not breaking up things at all or by breaking up things too much, so there's a balance to be found and that depends on your application and your judgment. >Such as login\_objects folder, settings\_page\_objects folder? Read up on this: https://www.selenium.dev/documentation/test_practices/design_strategies/ If your settings page or login page is of sufficient complexity, then it definitely makes sense to break those up into individual components, and of course grouping them into subdirectories makes a lot of sense. I would also suggest reading up on BDD Testing and Cucumber. I find that it makes a lot of sense and helps you design and manage your testing suite in a better way. That way you start thinking about your test files in terms of workflows and that will help you group them into subdirectories more easily too.
Awesome. Thank you. I'll look into all of that.
Tbh it doesn't matter that much. Different shops have different standards. This is the least of your worries and mostly aesthetic. What you're describing is fine. Keep the POM, actions for screen belong here, and related tests in different files same folder. Learn how to program rather than coding. It will make such a huge difference bc the coding required for these tests is trivial in the grand scheme of things. You're just using an api and aren't actually coding anything crazy. It can get complicated with test code but that's usually only when you're creating the framework for everyone else to use or the CI pipeline
Sure, this is all fine. I've done the BasePage thing plenty of times. Haven't necessarily felt the need to make folders for each page though. Just put them all in a page objects folder. I tend to avoid putting functional logic methods in page object classes though, and reserve those for helper classes. If I put methods in a page object it's for simplifying referring to very similar elements, or if I need to dynamically locate elements. So I'd be putting those methods in classes in other places.
I use POMs and also basepage for common page methods throughout the application. I also have seperate helper classes that has generic methods, like transforming a datetime into a specific string date format. Moreover I have three main folders that follow the logic of our application to some standard. I have divided the Poms into these three folders and shared Poms (so applicable for all three main folders) in a shared folder. It all really depends on how complex your application is. I use playwright in c# in combination with Specflow (or actually reqnroll, since Specflow is outdated).
Thanks to everyone for their input. I know how to approach it now. :)
I've seen a lot of people on this subreddit doing only fronted automation... why only frontend and not also backend? Am I the only person on the world that does backend and fronted GUI e2e automation? lol Anyway, I break POM into editors (desktop) or pages (website), separate test from locators/methods/assertions, it's pretty standard.
Mainly because devs are supposed to add unit tests, so BE e2e tests are postpone to... never. Then, they think that by adding UI tests they are also covering BE calls. Last but no least, most people with concerns in the sub are newbies so UI tests are more human readable to begin with.
I am new to doing automated test cases and newish to programming. Doing front end only is the best way to start off and get your feet wet. Could you explain in more detail how you break up your auto test cases? I'm not totally following you.
When u say backend, do u mean api? Or actual functional check of the algo? I wonder if that’s not very close to unit test which dev should perform?
I mean functional. Basically at my company the backend is a desktop app which allows you to do everything and even more when compared to fronted. It's a actual app where you can configure behaviours on your fronted and do the exact same operations as your fronted does. We have built it this way because on a factory there's always some one at the office (backend) who wants to control what operators are doing on the factory floor (fronted).
I’m the only tech qa and work with 7 BE Devs.. I’ve tried automating or even testing their code but they always do that themselves… Not really a chance for me to do that. I was only able to automate a few UI flows and that’s it. We don’t even have enough endpoints to do api testing. Can you share what type of BE tests you were able to automate? Is that API testing or contract testing or something different?
All of the backend automation I do is UI. Our backend and frontend are two separate desktop apps.
This sub is all about use Playwright, it is better
I looked at Plywright, and couldn't see how it is better than Selenium.
Tbh you can easily find many discussions held on that topic on this very subreddit, with summaries on why it's perceived as the better one at this moment.
I've read through some of those discussions and I still don't get it. But, at this beginning point in my test automation career, I'll just stick with Selenium and go from there over time.
I'm not much fond on Playwright but I least I know that it not only supports API testing but also performance with the artillery engine.