I have developed a cucumber based selenium automation framework and have used Page Object with Page Factory as the design pattern for it.
Below are different components of my automation framework :
Page Objects.
POJOs
sharedutilities
Feature Files
Config file
Expected Data folder
Extent config.xml
chromedriver.exe
Reports folder
I am not entirely satisfied with the way I have arranged these components inside maven project. There are multiple source folder for Maven like src/test/java, src/main/java, src/test/resources, src/main/resources, are there some standard set of guidelines on what to put inside these 4 folders depending on the components which I have mentioned above ?
General guidelines:
src/main/java contains your application code (.java files)
src/main/resources contains any non-code files that go with your application. for instance property files or config files for your application (if they are not Java config files, like your config.xml).
src/test/java contains any test code (.java files) for your application. If you mirror your package structure from src/main/java testing frameworks like Junit can automatically find the right classes to test without having to specify imports for them. In the case of Cucumber, this is where your step definitions go, as well as any other code that helps you perform your Cucumber tests (like the Page Objects in your example).
src/test/resources contains any non code files that go with your tests. In the case of Cucumber, this is where the feature files go. If you have a separate test config.xml that would go here.
If you have only test code, you might not have a src/main folder. I'd recommend locating your test code in the same repository as the system you're going to test, as this will make it easier to get fast feedback.
Regarding your question:
Page Objects -> src/test/java
POJOs - depending on whether they are application POJOs or test POJOs -> src/main/java or src/test/java respectively
sharedutilities - asusming this is code to help your tests -> src/test/java
Feature Files -> src/test/resources
Config file -> depends on whether this is for the application or test, and whether its code or xml.
Expected Data folder - not sure what you mean. Test files (like .json or something) might go in src/test/resources
Extent config.xml - probably src/test/resources
chromedriver.exe - might go in your root directory. (I might recommend against including .exe in your project; how are you going to deal with different OS?)
Reports folder -> would probably go to a target folder?
Hope this helps.
Related
i'm thinking about test automation structure using selenium, intelliJ ide, testng and maven. What You think about below:
I used one project and many directories beacuse i want to have just one pom file. If You could help me with testng file. How it should look like if i want to run all tests which are available in all "Tests" directories? What means click run and fire up all tests with "Test" testng annotations. Helpers, pages and tests directories exist becasue i will want to do this with POM & Page Factory.
#Sid below my pom. My testng.xml is empty currently because i do not know how to configure it to run all what i have in "Tests" directories.
Thank you for reply.
My tests are just examples with beforetests, test and aftertest annotations. Nothing to admire ;)
Too long for a comment:
I would assume your helper class is goin to have common functions. Also, depending on the size of your modules you may want to create more sub-module folders. You can also add a commons folder which contains generic steps and methods.
Now, if your modules are deployed completely independent of each other, you want to take a call on whether the code should reside with the app code or in one place like you have.
The structure would work out fine either ways. To run all the tests you need to include the folders / classes path in your testng files. IDE/Maven/testng dont care about your folder structure so long as you include all the paths correctly. Check out https://www.mkyong.com/unittest/testng-tutorial-5-suite-test/ for how to do that.
The follow structure
src
service
service1
Service.java
Service.properties
I want that the output generated by gradle would be
classes
service
service1
Service.class
Service.properties
So, I need that the files(.properties) keep in the same directory of the class after build, but the gradle copy the files .properties (resources) to another directory
how can I do it?
I assume you are trying to place them there so they can be loaded from the classpath? The best way to make them available to your class loader is to place them into src/main/resources which is part of the standard directory layout. Gradle will find them there and they will be placed at the root of your jar (by default I believe it ignores property files in src/main/java).
It would also be good to move your java files to to src/main/java. Using the standard directory layout is a convention that will help other developers understand the code. It also allows you to use certain tools out of the box with less configuration because those tools can make assumptions about where things live.
So the new structure would be like:
service1-project
src
main
java
service1.java
resources
service.properties
If you use the standard directory layout, I think you will achieve the end-result of what you are trying to do (which is really to load the properties file within Java). If for some reason you have to avoid the standard directory layout, then you have to start doing custom configuration (a downside of using a non-standard project layout). In Gradle, you should be able to do this by hooking into the Java Plugin's processSourceSetResources target.
Why there's a difference in Default Source Lookup Path between GWT and java launch configurations?
In multi-module projects instead of containing projects, the Default folder contains the class folders of those projects!
It causes "Source not found" errors when the debugger steps into a dependency project.
I know I can add projects manually. Just want to know why this difference is needed.
The only project in the list is the associated with the .launch.
GWT needs '.java' source files of dependencies to be able to compile (translate to js) while the Java launcher needs only '.class' compiled files.
I suppose you know GWT has a different way to manage dependencies (through modules within the same project), which is good for some advanced GWT practices like loading a module's js lazily (this feature doesn't work with "foreign" libs/projects).
So this could also be an answer for why eclipse GWT doesn't suppose you will have more projects (but more modules instead)
Finally if you really have an independent GWT lib that you're maintaining this is an issue as you said.
I'm trying to build a project structure like this:
Project
|--Web_module.war
|--Data_module.jar(Spring)
|--Util_module.jar
|--other public api...
which means, different modules should be packed into different jars, so i have to have more spring configurations(application-context.xml) for different modules (e.g. for data module and for web module).
My question, how could I organize all the configuration files to include them correctly in the web module.
Thanks in advance.
Plan to have a single eclipse project for each jar file that you anticipate.
Choose the jars files / eclipse projects as per your project functionality to be modular and self contained, as far as possible.
Use junit tests in each eclipse project to thoroughly test individual projects/modules, using spring unit test support
Each eclipse project will contain its own spring config context file eg Util_module project might contain a util-context.xml
Finally have an eclipse dynamic web project as a wrapper web application which will aggregate all your "module" projects
UI artifacts like HTML, JS, JSPs, etc plus java code which uses web application contexts like controllers, servlet filters etc should be included in the eclipse web project
In the eclipse web project's java build path, but the module "projects" as "required" projects
In the eclipse web project's deployment assembly, add module "projects" as dependencies.
now when you build-all and deploy the web app, all depending module projects will compile and deploy as well, but more importantly, all project functionality will be divided into seperate modular projects
setup dependencies between projects with care, so as not to introduce cyclic dependencies
dont be afraid to refactor project structure when needed to maintain clean and relevant modules
For your modules to publish their own configuration (and your main application to detect them automatically), you can, in your main applicationContext.xml, import other context.xml files from the classpath using a pattern with wildcards :
<import resource="classpath*:conf/moduleContext.xml" />
This tells spring to find and read files in all jars that match conf/moduleContext.xml.
Note there is a little limitation to this : you must have your context files in at least one directory (not in the root of the classpath). This is why in my example you have de "conf" directory.
I am using QT Creator and want to run my unit tests in a separate project. How do I reference the classes in the main project from my test project?
I realise this is an old question, but here are a few steps to make this easy:
Move most of your config from main_project.pro file to a main_project.pri file.
Use relative paths, relative to you *.pri or *.pro files, using $$PWD/path/to/file syntax where $$PWD is your *.pri or *.pro file location.
Include *.pri file using include($$PWD/main_project.pri)
Create a test project in your main_project folder.
In test/test.pro, add the line include($$PWD/../main_project.pri) to import the relevant configuration from you main_project.
I can add more details if there is some interest.
Once the basic setup is working, it's quite handy as you can create a separate project for each module you want to test plus global test_suite that run all the other tests. If you find that many test projects share some configuration, you can create a separate common.pri file in test/common to include in all your test projects.
Once, that's in place, it quite easy to generate a small script to automatically create a test project when in order to test a new module, resulting quite an efficient testing workflow...