Breaking up big projects into smaller and faster loading projects
Here is what worked best in the free version, and should work in Pro as well (my knowledge is limited using pro features or running tests in Tool). And prefer executing the tests in command-line with Apache Ant and reports in Junit Html style.
The key here is to design / divide the tests based on its functionality.
- Create a template project which includes importing of all WSDLs (for SOAP), Swagger definitions or WADL (for REST)
- Create a suite / tests with all commonly used. And it is important to disable to suite so that it is not executed when the project is run.
- Now each engineer who works on the project can have clone / copy of template and add suite and tests.
- Limit project with single suite. This makes each project very light and key to pain relief.
- Not sure how this approach works composite project is needed. But I guess, if each engineer works on different suites (i mean different project as it contains only suite), this approach can work.
- Since it is mentioned about multiple big projects, If needed, use separate directory for each project and use various artifacts such as data-sources, or any other property file etc. Even you can go further, create directory for suite or test as well if needed or if that deep directory structure helps.- When wsdl / swagger is imported, tool adds sample requests in the service / interfaces. Just remove them in template project, so they won't in the actual project as well.
- Have proper naming for the project and suite especially as they reflect in how it is shown to the users in the tool and in the report.Many use like Project 1, Test suite 1, Test case1 as they are the default names.
So, after copying / cloning the template project for creating tests, it is important to change the name of the each project appropriately. Otherwise one would end-up with confusion to identify which is project what if multiple projects are open in the tool.
- Limit the tool to design the tests and do initial dry runs to ensure everything is ok.
- Use testrunner utility to run command line or use the same with batch scripts or ant build scripts to execute.
- Create a separate java / groovy classes project for common tasks and create library jar and load it under bin/ext directory. Just call them with the required inputs instead doing copy paste of whole code again and again in each test case. Just calling them would be simple one or two lines (into groovy script test step). This also helps to make the changes in the classes at one place and use it every where without making any change in the groovy scripts of any test case as calling would still be same.
Here is the detailed steps on how to do it, blogged by our expert rupert_anderson
Having discussed about pain relief, also need to mention the drawbacks.- Now the number of projects will increase, running them in tool will be headache similar loading big project. That's where running command line can help!
One can use simple batch script or Ant tool or Apache Maven like mentioned earlier.
The advantage is that it OS independent unlike batch script (have to create separate for windows and non-windows).- In this approach, one may lose the advantages of the pro tool such as dash board, statics, history etc.
- Requires learning curve to be able to take the advantage of build tools. Running with Ant/Maven needs to learn how it works and create a build file.
Hope this helps to make your choice!
