среда, 20 февраля 2013 г.

SoapUI - the best ways of test projects integration.


I want to talk about some problem I encountered with while I created some tests with SoapUI tool.
The problem was - when we want to use some tests modules , which was developed by another person also with SoapUI - we often do the following:
1)Import someone's test suite to our project
2)use "Run TestCase" step for executing of test cases of someone's suite.
This is the standard way of integration of several test projects in SoapUI.
But. What will happened if this "someone" modified his test suite? Your imported test suite now doesn't work.
After that you will try to do the following:
1)get new version of "someone's" test suite and import it instead of old version.
After run of modified tests - you will get an exception, because SoapUi saved dependency to old version of "someone's" test suite and "doesn't understand" the new version of this suite.
I hope I well described the problem. Now I want to describe good(in my opinion) way to solve this problem.

First.
When you are writing your tests and you know that you will use someone's modules(in SoapUI terminology - this means - Test Suites), the better way is NOT to use "Run TestCase" from your tests. The better way is described on the image below:





On this image you can see 3 parts:
1)test suite you want to use
2)your tests
3)"Proxy".
What is "proxy"?  This is some layer for communication on your tests and methods you want to use. In my opinion it is very good practice to do such architecture in your test project. This layer is very useful because if you want to change something in calling someone's script - you will do it only in one place. For example, in all your tests you must create some account in some system before you could do your checks in tests. Someone gave you an a test suite, which has an a method(in soapUi terminology - test case) - "Create Customer". You could say "Yes, this is what I need" and after that add to your tests one step - Run TestCase - and link it with test case of  "someone's test suite". And it will work fine. In all your >50 tests(for example)
After some time some requirements are changed. And after account creation now you must confirm creation by using test method of modified "someone's" test suite. You will say "oh, now I must change all my tests. It will take about 1 or more days". Not a good situation.
For solving such problem - better use some proxy test method(in soapUI - Test case in some proxy Test Suite). In this proxy you will solve 2 problems : First - problem of integration with modified "someone's" test suite; Second - problem of easy modifying of your tests.
Let's start from second problem. Look at the example in one of the previous sentences(about customer creation). Let's imagine, that you create some method in proxy test suite, which role is - to call "someone's" test suite method - create customer. Now you use in all your tests not direct call of "someone's" test case, you use call of proxy method "create customer"(through Run TestCase), that's call "someone's" test case(like proxy).
After requirements are changed, and you must now cofirm customer creation. What you will do? Only one thing - you will add calling of creation confirmation ONLY in proxy test case! That's all! It will take only 10-15 minutes, and all your tests are updated! Cool!
After you will understand this approach of test architecture - your tests are more easy to modify.

What about "First" problem?(remember about modifying of "someone's" test suite , reimport and errors after that).
Run TestCase - good step, but not in all places. In our example with customer - imagine one thing - you are not using your proxy. What will happened if you modify and reimport "someone's" test suite? You will have errors in all of your tests cases! And you will need a lot of time to fix this problem. But if you use "proxy" (you use Run TestCase of your proxy test case) - after reimport you will have problem only in one place - in proxy test case, and you will fix it in several minutes.
Run TestCase - good, when you call your INTERNAL test cases of your INTERNAL test suites, that will not be often modified. When you call "someone's" test suite - it can be modified at any time and you will have errors after that.
How to solve this problem? You can use groovy script instead of "Run TestCase".
Use such code in your proxy test case:

def testCase = testRunner.testCase.testSuite.project.getTestSuiteByName("someone's_test_suite_name").
getTestCaseByName("create_customer");
testCase.setPropertyValue("somePropery","someValue");

def runner = testCase.run( new com.eviware.soapui.support.types.StringToObjectMap(), false);
def returnedValue =  testCase.getPropertyValue("returnedValue"); 

If you will use such code instead of standard "Run TestCase" step - after reimport of modified test suite you will have no errors.

This proxy level you can use not only for integration with "someone's" test suite. Imagine you have the file upload in every of your tests. If you want to modify an algorithm of file uploading - you will go into every test and modify it. Very slow process.
With "proxy"(in that way you may call it not proxy, maybe "Helper Suite" - that's good name for this suite) you can take out file uploading step into test case of helper suite(it also can take some params). And use Run TestCase for call of this uploading. After that you can modify algorithm only in one place, not in >50.


I hope this information will be useful. Sorry for my english. If you have some questions - please leave comments or write me on my email : sidelnikovmike@gmail.com
Thanks :)





author - Mikhail Sidelnikov
email: sidelnikovmike@gmail.com












Комментариев нет:

Отправить комментарий