Ask a Question

Breaking up big projects into smaller and faster loading projects

SOLVED
rajs2020
Frequent Contributor

Breaking up big projects into smaller and faster loading projects

I have seen some very large ReadyAPI projects which take about 15 minutes to load. It becomes a huge pain to load these projects 2-3 times each day. I would like to break them up into smaller projects so that they load faster i.e. in under 2 minutes. But, my concern is that I would have to repeat common functionality across all the pieces. Is it possible for one project to be able to use functionality inside another project?

 

For example, Project-main can be broken into Project-1 to 5. All suites in project-main require common functionality like get login token, get some test data etc. Can I create a project Project-c which will have all the common functionality and then project-1 to 5 can use them? Or do I have to repeat the common functionality in project1-5?

 

By the way, besides sharing common functionality, are there any other things I should note before I start breaking up a project into smaller projects ?

 

Keywords - Sharing between projects, shared projects, common projects, refactoring projects, breaking up a big project, project loads slowly.

 

PS - I have readyapi 3.0 and I simply cannot upgrade it for unknown reasons.

 

1 ACCEPTED SOLUTION

Accepted Solutions
nmrao
Community Hero

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

https://rupz.me/soapui-cookbook-bonus-recipes/1-how-to-develop-add-and-use-a-custom-groovy-library-i...


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!



Regards,
Rao.

View solution in original post

6 REPLIES 6
nmrao
Community Hero

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

https://rupz.me/soapui-cookbook-bonus-recipes/1-how-to-develop-add-and-use-a-custom-groovy-library-i...


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!



Regards,
Rao.

View solution in original post

nmrao
Community Hero

Re: Breaking up big projects into smaller and faster loading projects

@rajs2020, got chance to go thru the earlier reply?


Regards,
Rao.
richie
Community Hero

Re: Breaking up big projects into smaller and faster loading projects

Hey @nmrao,

Great response btw. Just an addition and question. Does splitting your projects across multiple workspaces help at all? Ive never done it myself, but im wondering if this would help at all? (as long as the "common stuff" was copied to each workspace)????

Ta

Rich
if this helped answer the post, could you please mark it as 'solved'? Also if you consider whether the title of your post is relevant? Perhaps if the post is solved, it might make sense to update the Subject header field of the post to something more descriptive? This will help people when searching for problems. Ta
nmrao
Community Hero

Re: Breaking up big projects into smaller and faster loading projects

@richie, workspace doesn't come in the picture at.
There is template project created. Just have a copy of it, rename it as per the functionality / suite. No need to open the template project once all the stuff reused is available there.


Regards,
Rao.
rajs2020
Frequent Contributor

Re: Breaking up big projects into smaller and faster loading projects

@nmrao - Thanks for the reply. I appreciate your enthusiasm and all the effort you put into answering questions. But I wonder if there are too many details in this answer too soon. It would be helpful to first get an overview of which approaches or methods are possible. Then, I'd ask for the details about implementing them. So, I'll first try to understand which approaches you are suggesting.

 

1 - Create a template project with all the common functionality like getting auth token, creating user accounts etc. Copy this project to make your small projects.

2 - Create a Groovy or Java library with all the common functionality and use it in your small projects.

 

Does this sound correct ? After that, we can get into the details like advantages/disadvantages and implementation details.

 

nmrao
Community Hero

Re: Breaking up big projects into smaller and faster loading projects

Not sure of the reason and terms "too much", "too soon" used in your reply. I went back to the original question to see what is sought. And your are true, you might not seek all this. It was given to provide the whole context for someone who needs it in one place instead bits and pieces.

This isn't the first time this issue discussed in the forum, by many members time to time. In fact, there was another thread couple of weeks back as well where there you took part. So it is addressed in general for the community.

Whatever information available can be consumed as needed, and the rest can be ignored.


Regards,
Rao.
cancel
Showing results for 
Search instead for 
Did you mean: