wcc / mdm testing with fitnesse userguide 1.0

WCC Testing With FitNesseWCC Testing With FitNesse– With an advanced WccXMLFixture

– Developed & Documented By

– JSSVPrasad.Buddha

– Test Specialist, IBM

2

WCC Testing With FitNesse User Guide IBM

Table Of ContentsAbstract .............................................................................................................................................................. 5

Document Revision History ............................................................................................................................... 6

1. WCC Testing ................................................................................................................................................... 7

1.1 XML Testing ............................................................................................................................................. 7

1.2 Limitations ................................................................................................................................................. 7

2. FitNesse Basics ............................................................................................................................................... 8

2.1 Testing With FitNesse ............................................................................................................................... 8

2.2 Testing WCC with FitNesse ...................................................................................................................... 9

2.3 Basic Setup to test WCC with FitNesse .................................................................................................. 10

2.4 Creating, Editing and maintenance of Test and Suite Pages ................................................................... 12

2.5 Test scripts and WCC Tests .................................................................................................................... 13

2.6 Table Processing ...................................................................................................................................... 14

2.7 Running Tests .......................................................................................................................................... 16

3. Basic Fixture ................................................................................................................................................. 19

3.1 What is Basic Fixture? ............................................................................................................................ 19

3.2 Syntax for Base Fixture ........................................................................................................................... 19

3.3 PassThrough ............................................................................................................................................ 21

3.4 Value ....................................................................................................................................................... 22

3.5 Not Value ................................................................................................................................................ 24

3.6 Count ....................................................................................................................................................... 24

3.7 Exists ....................................................................................................................................................... 25

3.8 Not Exists ................................................................................................................................................ 26

3.9 Variable Placeholder(!!) .......................................................................................................................... 26

3.10 Limitations ............................................................................................................................................. 27

3.10.1) Strict Adherence to data – Scripts have to be data specific ........................................................... 27

3.10.2) Limited ways of asserting .............................................................................................................. 27

3.10.3) Request and Response xml files not getting saved ........................................................................ 28

3.10.4) Only responses can be asserted and validated ................................................................................ 28

3.10.5) Improper Handling of Exceptions .................................................................................................. 28

3.11 Example Test ......................................................................................................................................... 29

4. Customized Fixture ....................................................................................................................................... 31

4.1 New Syntax ............................................................................................................................................. 31

Prasad Buddha

3


4.2 Behavioral Modifications ........................................................................................................................ 32

4.2.1) Storing request and response xml files ............................................................................................. 32

4.2.2) XPath validations on Request xml .................................................................................................. 33

4.2.3) Output Captured ............................................................................................................................... 33

4.2.4) Properties File .................................................................................................................................. 35

4.2.5) Testing the performance ................................................................................................................... 36

4.2.6) Action Keyword behavioral changes ............................................................................................... 37

4.3 File Handlers ........................................................................................................................................... 38

4.3.1) ByPass .............................................................................................................................................. 38

4.3.2) Pass ................................................................................................................................................... 39

4.3.3) Force ................................................................................................................................................. 39

4.3.4) Optional ............................................................................................................................................ 40

4.3.5) No File .............................................................................................................................................. 41

4.4 Predefined Variables ............................................................................................................................... 42

4.4.1) ?UniqueKey? .................................................................................................................................... 42

4.4.2) ?UniqueNumber? ............................................................................................................................. 42

4.4.3) ?YYYY?, ?MM?, ?DD? ................................................................................................................... 43

4.4.4) ?CreateBackup? ................................................................................................................................ 43

4.5 New Variable Placeholder ....................................................................................................................... 44

4.5.1) ## ...................................................................................................................................................... 44

4.6 New Passthroughs ................................................................................................................................... 45

4.6.1) Count PassThrough .......................................................................................................................... 45

4.6.2) Part PassThrough ............................................................................................................................. 45

4.6.3) CPassThrough .................................................................................................................................. 47

4.6.4) CPart PassThrough ........................................................................................................................... 48

4.6.5) CPassThrough Or Copy ................................................................................................................... 49

4.7 New Assertions ........................................................................................................................................ 50

4.7.1) Value IgnoreCase ............................................................................................................................. 50

4.7.2) Contains ............................................................................................................................................ 51

4.7.3) Is Empty ........................................................................................................................................... 51

4.7.4) Not Empty ........................................................................................................................................ 51

4.7.5) Length .............................................................................................................................................. 52

4.7.6) Is PastDate ........................................................................................................................................ 52

4.7.7) Is FutureDate .................................................................................................................................... 52

Prasad Buddha

4


4.7.8) Is Today ............................................................................................................................................ 53

4.7.9) Is Before ........................................................................................................................................... 54

4.7.10) Is After ........................................................................................................................................... 55

4.7.11) Is SameDate ................................................................................................................................... 55

4.7.12) CValue ............................................................................................................................................ 56

4.7.13) CValue IgnoreCase ........................................................................................................................ 60

4.7.14) CContains ....................................................................................................................................... 60

4.7.15) All CValue IgnoreCase .................................................................................................................. 61

4.7.16) All CContains ................................................................................................................................. 62

4.8 Miscellaneous Key words ....................................................................................................................... 63

4.8.1) Copy ................................................................................................................................................. 63

4.8.2) CCopy .............................................................................................................................................. 64

4.8.3) Add ................................................................................................................................................... 65

4.8.4) If Variable Exists … EndIf .............................................................................................................. 65

4.8.5) Display Value ................................................................................................................................... 66

4.8.6) Display Count ................................................................................................................................... 67

4.8.7) Exception .......................................................................................................................................... 67

4.8.8) Remind ............................................................................................................................................. 67

4.8.9) # ........................................................................................................................................................ 67

4.8.10) Reset ............................................................................................................................................... 67

4.8.11) Reset All ......................................................................................................................................... 68

4.9 Advantages of Customized fixture .......................................................................................................... 68

4.9.1) Separating scripts from data ............................................................................................................. 68

4.9.2) More Actions .................................................................................................................................... 69

4.9.3) Request as well as response xml files can be validated ................................................................... 70

4.9.4) Requests and Responses getting saved for future reference ............................................................ 70

4.9.5) Unique Key generators and Unique Number generators and several other predefined variables .... 70

4.9.6) Customized log makes it easy to open xml files for debugging ....................................................... 70

5. Re-usability ................................................................................................................................................... 71

5.1 Designing the Reusable Components ...................................................................................................... 72

5.2 Including the Reusable Components ....................................................................................................... 74

Appendix – I: Syntax of All the Actions .......................................................................................................... 77

Appendix – II: Actions & Number of Tags ...................................................................................................... 78

Prasad Buddha

5


AbstractAbstractThis document discusses about an open source tool called FitNesse and how it is used to test WCC.

This document starts by giving a brief idea about FitNesse and its features. Then it discusses about a plug-in that is developed to enable simple and basic unit testing of WCC xml transactions. It then explores the features, I have added to the fixture by redesigning it to make many things possible, which are impossible with the fixture before those customizations. This document explains how all these new features to the plug-in (fixture) make WCC testing with FitNesse easier and provide more testability.

Why do we need a different tool for xml testing? The answer is simple. The comparison we have to do in this case is different. We are not comparing two similar xml files with different data but two different xml files with different structure. We may even have to compare two different tags in the same file. Doing these things in the regular xml comparison tools is extremely complex. Therefore, we need a different set of tools to do just that. This document tells how to do that.

As market conditions drive companies to become more customer-centric, many organizations are turning to packaged Customer Data Integration (CDI) solutions to help enable their transformation. With WebSphere Customer Center, IBM® markets the industry’s most robust and mature Customer Data Integration solution. WCC’s unique set of 500+ pre-built ‘business services’ enables organizations of all sizes to build a solid foundation of ‘actionable’ customer data for consumption by front and back-office systems in real-time or in batch.

The Customers that are using WebSphere Customer Center or simply WCC are growing in quick succession. So many clients like SunTrust are opting for WCC for their customer data management and customizing the product to suit their needs. As the number OOTB transactions (Out Of The Box or simply readymade transactions) are growing and customized transactions are increasing at a high pace, the testing of WCC projects is getting more and more complex. The back end testing of WCC involves execution of xml transactions and comparing request and response xml files of various transactions. We need to analyze many xml files in a very short span of time.

‘Whether the xml files are being generated properly or not?’, ‘whether the xml files contain correct data in correct tags or not?’ are the main questions to be answered by the test team while testing xml transactions. In such a scenario, where, xml files are getting bigger and transactions becoming complex the testing is a nightmare in this agile world. Whenever a new requirement comes, it is not enough if you just test the new requirement, we have to rerun all the regression test cases and analyze all the xml files repeatedly. Analyzing all the xml files manually is a gigantic task and requires large-scale human effort, time, and cost.

This document does not speak about how to customize WccXMLFixture or how to create new fixtures. They are out of scope for this document. This document does not even give many details about WCC.

Prasad Buddha

6


Document Revision HistoryDocument Revision History

Revision Date Revision Comment Version Revision Author

2009-07-21 Initial Draft 0.9 JSSVPrasad.Buddha

2009-08-17 Base version 1.0 JSSVPrasad.Buddha

Prasad Buddha

7


1.1.WCC TestingWCC TestingWCC uses a request/response framework to maintain data. The request can be through an xml re

quest or through UI provided by WCC. Hence, WCC Testing can be either xml testing or DSUI testing. DSUI testing is out of scope for this document. The xml request/response framework consists of the following simple steps.

xml request is created and submitted to WCC. This request contains information about what exactly has to be done.

WCC then reads the xml request and goes through each of the three layers detailed above. Using its unified view of information WCC attempts to perform action specified within xml request, while ensuring that customer data remain consistent.

WCC creates an xml response that contains a success message with data related to the request or a failure message if the transaction is unsuccessful.

1.1 XML Testingxml Testing beginning with a mere preparation of request xml files, execute the transaction by hit

ting the WCC and get the response xml file, compare the input and output xml files, check for missing and misplaced data to identify defects and save the xml files for future reference.

1.2 LimitationsThere are quite a few challenges for any xml testing. There is no easy way to automate xml testing

so far and manual testing has its own set of setbacks. Here are they. The biggest issue is time. xml files may contain less than two to more than thousands of tags. Executing the transaction and comparing all the tags of all the xml files repeatedly for every re

gression cycle, is a very tedious task. Doing everything manually can cause errors to creep in and bugs to escape from the early stages

of testing.Automating the testing is a solution to overcome the limitations set by manual testing, but as we

discussed, so far there is no best way to automate xml testing. After 8 months of experimentation and successful implementation, we came to a near perfect solution to validate and compare xml files.

The solution for this problem is extending a tool named FitNesse and creating a plug-in like component (let us call it Fixture from here on wards) that does what we needed and the solution surprisingly comes at free of cost. FitNesse is a web server, a WIKI, and an open source software-testing tool. It is based on Ward Cunningham’s Framework for Integrated Test. FitNesse is designed to support acceptance testing. With the new features, we use it for a lot more than simple acceptance testing in our project; we use it in all levels of testing WCC xml services in our project.

Prasad Buddha

8


2.2.FitNesse BasicsFitNesse BasicsFitNesse enables customers, testers, and programmers to learn what their software should do, and

to compare automatically that to what it actually does. It compares customers’ expectations to actual results. From another perspective, FitNesse is a lightweight, open-source framework that makes it easy for software teams to organize and run test scripts etc.

FitNesse is a software-testing tool - You can collaboratively define Acceptance Tests -- web pages containing simple tables of inputs

and expected outputs. Run those tests and see the results.

FitNesse is a wiki - You can easily create and edit pages. It uses wiki syntax to create test tables.

FitNesse is a web server - It requires no configuration or setup. Just run it and then direct your browser to the machine where it is running.

2.1 Testing With FitNesseTo write a test case in FitNesse, tester needs to create a new test Wiki Page. In that page, tester cre

ates test tables, which contain information required for the test case. The test page should also contain a construct called a Fixture. It can be program to be tested, or it can even be an adapter between FitNesse

and application to be tested. In some test cases, a single fixture is all that is needed. However, many times a test case may require more than just one fixture to ensure the proper functionality.

One key concept of the FitNesse is that Wiki Pages are put together in a hierarchy. By leveraging this capability, testers can group functional tests together and run them in what is called a Suite. A Suite

Prasad Buddha

Figure 1: FitNesse Architecture

9


will execute all tests that are below it within the hierarchy. FitNesse also allows you to create Suites of Suites.

2.2 Testing WCC with FitNesseFitNesse does not know anything about Extensible Markup Language (XML) or WebSphere Cus

tomer Center (WCC). However, how do we use it to test WCC? Simply, by extending it with a fixture (call it a plug-in). Fixture is a piece of code that does what FitNesse cannot do. In this scenario, the fixture is a compiled Java class file. In order to test WCC transaction, we need to create a fixture that communicates between FitNesse and WCC and sends the request to WCC; it receives the response and validates the xml against our automation script and tells FitNesse, whether the test has passed or failed.

Wait a moment, if the fixture communicates to WCC by sending the request and receiving the response xml files and if fixture validates the xml against the automation script, why do we need FitNesse? Why does the fixture have to tell FitNesse, whether the test case has passed or failed?

As explained earlier, FitNesse is a wiki server; it helps us to organize all our test scripts in the form or Wiki pages. It is a web server, it enables multiple people to work on automation scripts by keeping at central location and serve the test scripts like web pages to testers. Even when fixture is doing all the work, at some point of time the fixture has to be called, FitNesse is the calling application. It supplies the fixture right automation script at right time, when the tester wants to test. FitNesse receives the statistics, whether the tests have passed or failed and creates a report that is easy to debug.

Therefore, neither just FitNesse, nor just fixture is enough to test our application; we need both. However, you do not have to worry; a fixture is already developed to test WCC xml services. You just have to use it. All you need is you need to have is JRE installed in your system, running copy of FitNesse and a little knowledge on how to use the fixture. The name of the fixture is WccXMLFixture.

Looking at the picture above we can conclude that user can interact with FitNesse for two purposes, either for creating test automation scripts or for testing the WCC services. While creating automation scripts, the tester uses FitNesse UI and saves the script through it. In that phase, neither Fixture, nor WCC comes into action. While testing, the user asks FitNesse to execute test cases; FitNesse takes the

Prasad Buddha

Figure 2: Interactions between User, FitNesse, Fixture and WCC

10


scripts that are created earlier and sends them to WccXMLFixture. Fixture collects the xml files as per the path mentioned in the script. The fixture then converts the xml file into a string and then passes it to WCC. WCC then sends back a response xml in the form of a string. The Fixture then saves the response xml string as xml file. Then the validates the request and response xml files depending on the automation script to find out if there are any issues, and if it finds any discrepancies, it sends the test status and relevant error message to FitNesse. FitNesse prepares a report for easy debug and presents it to the tester.

2.3 Basic Setup to test WCC with FitNesseFitNesse is available at http://fitnesse.org/FitNesse.DownLoad. Extract the fitnesse.zip to some loc

ation in local machine. You can start the FitNesse server by executing the class file fitnesse.FitNesse. The command line arguments for FitNesse class file usage are as follows… java fitnesse.FitNesse [-pdrleoa] -p <port number> {80} -d <working directory> {.} -r <page root directory> {FitNesseRoot} -l <log directory> {no logging} -e <days> {14} Number of days before page versions expire -o omit updates -a {user: pwd | user-file-name} enable authentication.

To run just FitNesse it is enough if we have FitNesse along with JRE installed in the system. However, to test WCC, as explained in the previous section, we are going to need the following additionally.

wccFitnesse.jar and supporting jar files WAS Environment files that can be found in folder base_v6

The wccFitnesse.jar file contains the WccXMLFixture and SoapXMLFixture. The wccFitnesse.jar and supporting jars are available in the zip file that is attached along with this document. In order to communicate with WCC, and handle some exceptional cases the fixture needs WAS environment files. Base_v6 folder is usually found at the path <Drive>:\Program Files\IBM\Rational\SDP\6.0\runtimes, if WAS is installed with default settings. Generally WAS environment files will be inside base_v6\lib. There is another folder inside base_v6\java, this folder is not required if the system already has JRE installed at another location.

The file ‘run.bat’, which can be found in extracted folder of fitnesse.zip, has default settings to run and start the FitNesse web server. Open the folder in which you have extracted the fitnesse.zip and double-click run.bat. It executes the FitNesse class file to start the server. If the port 80 is free in the local machine and if JRE path and WAS environment files path is as mentioned in the run.bat the FitNesse server will be successfully started, and you will see a command prompt window stating that the server is started. If you get an error, probably there might be some problem with command in run.bat; here is the run.bat we used…SET WAS_HOME=C:\Program Files\IBM\Rational\SDP\6.0\runtimes\base_v6SET JAVA_HOME=%WAS_HOME%\javaCD BaseFitnesse"%JAVA_HOME%\bin\java" -classpath lib/fitnesse.jar fitnesse.FitNesse -p 8072 -d ../FitNesse %2 %3 %4 %5CD..pause

The parameters WAS_HOME, JAVA_HOME, and port may have to be changed. Everything else works as it is without any change. For complete usage, refer FitNesse user guide.

Once the FitNesse server is started, the FitNesse can be accessed via the URL Http://<ipaddress>:<port> in a browser. Here is the home page of the tool when we start fitnesse server. You may not find everything you see in the page as shown in the screen shot in Figure 3, WCC Tests you see in the figure is specific to the pages created in FitNesse to organize automation scripts in our project.

Prasad Buddha

11


To be able to run the WCC tests, there are a couple of variables that must be defined in each test page, or instead they can be defined in a home page for which all other test script pages are children. The variables are…

classpath COMMAND_PATTERN

Classpath tells FitNesse where to search for required class files. COMMAND_PATTERN tells FitNesse where to find WAS environment files and JRE environment. Classpath variable is defined using the syntax ‘!path <path>’.

Here is the example for classpath variable definition…! / . path lib fitnesse jar! / .path lib fitlibrary jar! ./ / .path WCCFixture wccFitnesse zip! ./ / .path WCCFixture DWLCommonServices jar! ./ / 1.0.path WCCFixture xmlunit jar! ./ / .path WCCFixture ace jar! ./ / 2 _ _ .path WCCFixture j ee ce client jar! ./ / 4 -1.2.9.path WCCFixture log j jar! ./ / - .path WCCFixture commons logging jar! ./ / - .path WCCFixture commons io jar! ./ / - -2.1.path WCCFixture commons lang jar

Here is the example of COMMAND_PATTERN variable definition…! _ (“ :/define COMMAND PATTERN C Program

/ / / /6.0/ / _ 6/ / / / - "% " -Files IBM Rational SDP runtimes base v java jre bin java” cp p D . . =".\ \ " - . . =“ :/java endorsed dirs lib endorsed D java ext dirs C Program / / / /6.0/ / _ 6/ / / ; :/Files IBM Rational SDP runtimes base v java jre lib C Program / / / /6.0/ / _ 6/ / / / ; :/Files IBM Rational SDP runtimes base v java jre lib ext C Program / / / /6.0/ / _ 6/ % )Files IBM Rational SDP runtimes base v lib” m

To understand the way these definitions work, refer to the FitNesse user guide. You do not have to worry about the setting up these variables; Setup provided along with this document defines all the variables required and provides the required jar files.

Prasad Buddha

Figure 3: Home Page Of FitNesse in our project

12


2.4 Creating, Editing and maintenance of Test and Suite PagesFitNesse is not a standalone tool. It is a browser-based tool. It acts like a website. Each test script is

a page in FitNesse. The test scripts are organized as wiki pages in a hierarchical manner. Each page can be a test page (a page with automation script) or a suite page (a page in which other test or suite pages are grouped by creating as sibling or children) or both. Test page contains a valid automation script along with the other information. Suite page contains links to other test pages and act like a parent page for the test pages that are defined as children. Children pages inherit the variables defined in the parent page. The suite pages look as shown in the Figure 4 and the test page looks as shown in Figure 5.

Click Edit button in the left menu bar to edit a page. This will bring you to a new page with a text box containing the editable text of the original page. The Text box has all the page content in WIKI markup language (raw script); you do not see the tables or links anymore. Look at Figure 6 for reference. Once the Page is saved, it will be displayed in form of a table as in the Figure 5, as per the wiki markup rules.

Prasad Buddha

Figure 6: FitNesse Page in edit mode

Figure 5: FitNesse page with Test script Figure 4: Suite page referring other pages

13


A new page can be created while in edit mode of another page. All we need to do is typing a new name following page-naming rules. FitNesse automatically recognizes any word in the page as qualified name for page creation, if the word satisfies the following rules…

1. The word must be in Camel Case (each word starting with a capital letter) 2. There must be at least two capital letters (ex: NewPage, QualitY) 3. It must start with an alphabet(A-Z) or a ‘^’ 4. There must not be two consecutive capital letters 5. There must not be any spaces or special characters

For example, if you type QualitY or TestAddPerson123 in the edit mode of SandBox, and save the page, a hyperlinked question mark will appear beside the above word. Click on the question mark, and a new page will be displayed with an empty text box be opened with the page name QualitY or TestAddPerson123 type something in the page and hit save. You have just created a sibling page for SandBox, if you want to create the page as a child, you should type ^QualitY or ^TestAddPerson123 while in edit mode of SandBox.

Whenever such a word (which is qualified to be the name for a page) is typed in edit mode of a page and saved, a hyperlinked question mark appears after that word as in Figure 7. Clicking on that link takes us to edit mode of the new page. The word we typed in edit mode of parent page will be the name of the new page. We can enter anything we want, it can be our test script, or it can be something else depending on the requirement. Observe that there is no question mark beside ‘Sample Tests’ in the figure as it is not a qualified page name (the two words are separated with a space).

For more information on WIKI markup language and creating tests and suites, refer to the user guide that comes with FitNesse.

2.5 Test scripts and WCC TestsIf we go into the details of a test page, all tests in FitNesse are in the form of tables, we call it

a test-table henceforth. We use wiki markup language to create tables. Cells in a table are created by separating the text with piped character ‘|’. New rows are created by starting a new line with a ‘|’ and ending with a ‘|’. To create a table that looks like this…

eg.Divisionnumerator denominator Quotient?10 2 512.6 3 4.2100 4 33

We will just have to write the following text in edit page and save…!| . |eg Division| | | ?|numerator denominator quotient|10|2|5||12.6|3|4.2||100|4|33|

We do not have to understand how the above test table works except for two things. The first thing you have to know is about the first line. The first line in the table tells that the fixture that is going to be used is eg.Division (if you are aware of Java, you can guess that ‘eg’ is a package and Division is a class in that package). The other thing you have to know is that the syntax you find from second line is the syntax expected by the fixture. The number of columns may vary according to the number of inputs required for

Prasad Buddha

Figure 7: Question marks beside words that are eligible to be a page name

14


the fixture and the number of outputs that are to be verified. Let us not go into any more details of the above table.

Similarly, if we have to test WCC, our first line should tell FitNesse that we are going to use WccXMLFixture. From second line onwards, it will be the syntax expected by WccXMLFixture. The syntax can mean that the URL for WCC server, xml file name, the action keywords, representing tags, and defining variables to compare xml files etc.

2.6 Table ProcessingA fitnesse test script can have the following: Test tables, comments, and general text. All that we

have to be learning is how to write test tables. Comments and general text can be ignored, as they have nothing to do with testing except for providing more information to the tester.

In edit mode (normal text or raw wiki script view) of a typical page, there can be different parts in the script. The Portions marked in Yellow in Figure 8 are the real testing portions of the scripts. They are test tables. They start with ‘!|com.ibm.wcc.fitnesse.WccXMLFixture|’, and end with an empty line. The com.ibm.wcc.fitnesse.WccXMLFixture is applicable only for our WCC testing of xml transactions.

The next area marked in brown is a multi-line comment. A multi-line comment start with a triple opening braces ‘{{{’ and ends with a triple closing braces ‘}}}’. Whatever you keep between those two triple braces, will be considered as a block comment. Even if you place test tables, they will be ignored while running the script.

However, if you look at the second yellow portion, you can see that the table does not end with an empty line. It ends with a commented line. A single line comment starts with ‘#’. Whatever you write after # is just a comment and will be ignored. There are two lines in the area after second test table.

The first portion in green is some text. This is not a comment but it is not a part of the test script. It is just used to provide more clarity. You may also use such text to give the various steps in a test case, expected result, test case description and what not. However, there is no rule that these portions have to be in the places as shown below. Any portion can be at any place you need it. A test script can start with a

Prasad Buddha

Figure 8: Various parts in a fitnesse page

15


straight test table. However, once test-table starts, the subsequent lines must start with a ‘|’ or else the test table ends. Once you save the script, it looks as in Figure 9…

If you have observed, you do not see certain characters in Figure 9. The first portion does not change much. However, the test table portion looks like a real table now. Then the block comment portion does not look like a test table, even if there is a test table between {{{ and }}}. FitNesse does not consider the text between those two characters as test script, so it displays the text same as we entered in edit mode. The next test table also appears like a test table. However, you do not see the next lines as in edit page, as those two are single line comments. FitNesse does not show you whatever you commented with a ‘#’.

If exclamation is missing from the beginning of the first line of a test-table, FitNesse does not consider it as a test table. However, it looks like a table. You may find ‘----’ in the script, it is just to add a horizontal line. There are many more. However, I want to confine this discussion to just test-tables. Not all the other things are so important, and you can find out in internet if you search for Wiki Syntax.

By following all these rules, you can make scripts with any level of complexity. It does not matter how long the script is. It all boils down to one point, what is the number of test tables that are not commented?

Prasad Buddha

Figure 9: Once the script is saved, it will be rendered as per wiki syntax by FitNesse

16


2.7 Running TestsIt is the simplest part. Just click the test button beside the test table.

Once we click the Test button, the WccXMLFixture we mentioned in the first row of the test-table will come into action, and read the values we provided in the subsequent rows of the test-table and communicates between the FitNesse and WCC.

Fixture evaluates all the rows in the test tables. Assertions that pass turns into green and failed assertions turn into red.

Observe the top-left corner of Figure 11, you will find a hyperlink that says Output Captured, and clicking on that link will take us to the logs. Any exception while running the scripts, the request and response xml files. Here is the screen-shot when we click Output Captured. The output logs has various details like when it is executed, the time taken to execute the test case and request and response xml files, if there are any exceptions, they will be printed to this log.

Prasad Buddha

Figure 10: Test Button for running script

Figure 11: Running the script will change the color of cells depending on the Pass or Fail status

Figure 12: Test case execution with failures turning into red

17


Prasad Buddha

Figure 13: Output Captured Log

:

18


Observe the Report band that tells how many action lines passed and how many failed. If we run an entire suite the report band also displays, how many test cases failed and how many passed along with the number of assertions passed and failed. Along with the report band, it also displays status of each test when we run a suite, and results of each test are appended to the same suite results page as show below.

Prasad Buddha

Figure 14: Report band turns green and displays number of assertion passed

Figure 15: When some exception occurs, Report band turns into Yellow and observe number of exceptions

Figure 17: Any failed action lines will turn the report band red

Figure 16: If nothing else passed and some rows are ignored the report band turns into Grey, here some passed

Figure 18: Test Suite execution

19


3.3.Basic FixtureBasic FixtureAs explained so far… FitNesse does not have any in-built capabilities to test WCC, to be precise it

does not even have in-built capabilities to read and validate xml files. We need an additional component or plug-in that reads xml, modifies them, sends a request to WCC server, receives response and compares the xml tags. An additional component or plug-in or fixture is required to do all these tasks. Luckily, it is already created back in 2006. In this document, we call it a Basic Fixture, because it lacks certain features that are required to be able to use it as an effective alternate for manual testing and a full-scale tool for automating WCC testing. I have added many features that are required for this fixture to be a full-scale alternative to manual testing. I call it Customized Fixture.

3.1 What is Basic Fixture?FitNesse provides an extendable framework to write plug-ins that can act like a middle ware

between FitNesse and the application to be tested. If the input parameters and output parameters are simple strings, the application can be directly tested. However, WCC does not work on simple string parameters; it works based on a request and response framework. The xml files are not like simple strings they can get complex even for simple transactions. It does everything that is mentioned in the above paragraph, send a request to WCC server, receive a response, and validate the response. It can change the request depending on specific run-time values as mentioned in the script.

As we have seen in previous chapter, every test script is in a form of tables. So is the syntax for WCC Tests too. Let us have a detailed look at the syntax.

3.2 Syntax for Base FixtureEach test script is a combination of multiple test tables; each table is for one xml. One table can

send one request to WCC and receive its response from WCC. The actions (passthrough and other assertions) work only on response xml file.

The syntax should answer many questions. The syntax should tell FitNesse, to use WccXMLFixture as the fixture; it should tell the fixture about the WCC server URL; it should mention the instance name of WCC on server. There must be a provision to tell fixture, which xml file, should be sent to WCC as a request. There must be a provision to tell the fixture which tag to be used for validation. WccXMLFixture uses XPath for that. There must be a provision to tell the fixture about variables that are to be used as a part of script. Therefore, here is how the syntax for WccXMLFixture is defined.

The above table tells many things about the syntax required for WCC testing. The first line is the fixture line com.ibm.wcc.fitnesse.WccXMLFixture; WccXMLFixture is a Java class file that is in the package com.ibm.wcc.fitnessse. The second line consists of two cells, first cell is for telling fixture, the in

Prasad Buddha

Illustration 1: Syntax for Basic WccXMLFixture

com.ibm.wcc.fitnesse.WccXMLFixtureWCC Instance Name WCC Provider URLXML file name

Action Keyword XPath of the tag to be used from response XML

Action Keyword Xpath of the tag to be used from response XML

Variable or constant

::

Variable or constant

20


stance name and the second cell is to tell fixture the URL of the WCC server. The third cell is for mentioning the name of the xml file.

From the fourth line to end of the table, the first cell is for action keyword (either passthrough or assertions) to work on the tags. The second cell is for XPath of the tag to work on. The first two cells are mandatory and the third cell is conditional. It becomes either mandatory or optional depending on the first cell. Here is an example of a small test table.

!| . . . . |com ibm wcc fitnesse WccXMLFixture| { }| { }|$ WCCInstanceName $ WCCProviderUrl| { } \ . |$ WCCInputDirBase Samples addPerson xml| |/ / / / |Not Exists TCRMService TxResponse TxResult ResultCode| |/ / / / | |Value TCRMService TxResponse TxResult ResultCode SUCCESS| |/ / / / / | ?|PassThrough TCRMService TxResponse ResponseObject TCRMPersonBObj PartyId partyID

The small portions of wiki script that starts with ‘${’ and ends with ‘}’ are the fitnesse-page-variables. These variables are used to simplify changing portions of fitnesse script. The fitnesse-page-variables can be defined using the keyword define. Those variables can be used anywhere in the fitnesse pages. Here is the syntax to create page-variables…

! < > {< >}define Variable Name value

Here is the example to create fitnesse page-variable…! { ://10.19.6.214:28 10}define WCCProviderUrl iiop

To define a page-variable the first character of the line must be an exclamation, which is immediately followed by the keyword define. Therefore, in the above example, WCCProviderUrl is the variable and iiop://10.19.6.241 is the value in the variable. To use the variable anywhere inside fitnesse scripts, you have to use the syntax ${<variable name>}. Thus, let us call ${ and } as the variable placeholders for page-variables.

Is it confusing? Let us rephrase it. We define page-variables and store a value inside using the !define keyword, we use those variables in subsequent children pages to provide flexibility, to get the value inside the variables, we enclose the variable name with page-variable placeholders. If you ask me the difference between page-variables and script variables, page-variables are static, they do not change once the test is started to run, they are like constants, you know what their values are, before running a test. The script variables are dynamic, they will be created at run-time. They exist as long as the test runs. You may not be able to find what their values will be until running the script.

The number of cells from fourth row can vary depending on the kind of validation or work, we want to do on the tag. We use fixture-defined keywords in the first cell of the table from fourth row onwards. Sometimes you want to fetch value in a tag and compare it to another value. In such a case, you need to tell fixture that you want to compare, then which tag to compare and finally which value to compare. To do this we need to tell the fixture two things(the tag and the value). Sometimes, we just want to check whether a tag is empty. To do that, we have to tell the fixture that we want to find out if a tag is empty. Therefore, here we need only one cell(tag). We tell fixture about what we want to do using fixture keywords. We tell fixture about the path of the tag using XPath notation. We give words of our own choice to name variables or values.

Prasad Buddha

Figure 19: Page-variable Vs. Script Variable

21


With this basic version of fixture, two types of key words can be used in the first cell of test-table from the fourth row. One is PassThrough and the other type is assertion. PassThrough is used for storing value from a tag and assertions are a way to ensure that a tag is according to our need. For example, to check that it has a value what we expected, or to check if it is empty etc., Let us go through all the fixture keywords in the following sections of this document. PassThrough is the only keyword that comes under PassThrough type. Exists, Not Exists, Value, Not Value, and Count are assertion type of keywords because they assert.

3.3 PassThroughPassThrough is a keyword that can be

used to get the value from an xml tag and store it in a variable. It expects two parameters, a valid XPath that resolves to a unique tag and a variable.

The flow of pass-through begins with checking if Cell 2 and Cell 3 available. Once both the validations succeeded, it checks if the XPath provided is valid or not. If required cells are not available, it throws an exception.

If the XPath is valid, the fixture checks if a unique tag can be resolved for the XPath in the xml file. Pass-through requires the XPath to match a single tag in xml file. If an XPath matches no tag, it is an error. If an XPath matches more than one tag, the fixture cannot decide which tag to get the value from, so it throws an error. Even If the XPath matches a single tag but if the tag is empty, it is still an error.

Once a unique tag matches the XPath and a string is found in the tag, the fixture fetches the value inside the tag and stores it in a variable with the name provided in the cell 3. There are no naming rules for script variables. As a standard and convention we are having a question mark at the end of every variable like partyID?, addresslineone?.

The flow of operations in PassThrough is presented in the flowchart in Figure 20. The flow takes the green path when everything goes as expected and the red path is taken whenever some exception occurs.

PassThrough is the only way in which you can take the value from a tag and store it in a variable. You can use this variable for comparisons or as input data for the subsequent xml files. Below is a screen-shot for example usage of PassThrough.

Prasad Buddha

Figure 20: Flow of PassThrough

22


Figure 21: Example use of Passthrough in a fitnesse script

As explained previously, the first cell must always be the action keyword, in this case it is PassThrough and the second cell is for XPath of the tag for the PassThrough to work on (whatever you see something similar to /TCRMService/TxResponse/Response..) and the third cell is for variable partyID? The raw wiki script (in edit window) for the line highlighted in Figure 21 will be as below…

| |/ / / / / | ?|PassThrough TCRMService TxResponse ResponseObject TCRMPersonBObj PartyId partyID

When the test is executed, the flow of execution will be same as shown in flowchart. It Passes or fails accordingly. Here are few examples when we run PassThrough in different scenarios.

Three different scenarios are depicted in the above screen-shot The Green Cell is an indication that everything went as expected and PassThrough successfully saved the value inside AddressIdPK tag in the variable AddressIdPK?. It also displayed the value stored in that variable.

The other two scenarios are in red, so they are failed scenarios, one scenario failed because of the tag is not found and the other case is when more than one tag is found with the same XPath.

You have to be careful while writing XPath, because an Invalid XPath like /TCRMService/TCRMTx/TCRMObject/TCRMPersonBObj/TCRMPartyIdentificationBObj[IdentificationType=100012/IdentificationNumber ('[' is started but is not closed with a ']') can crash the fixture because the basic fixture is not designed to handle exceptions of this kind. To learn completely about XPath, Google it, w3schools.org has a very good tutorial on Xpath.

3.4 ValueValue is an Assertion type of action keyword. This asserts that the value in the tag is equal to the

value provided in the third cell of the test-table. Here are two different usages of Value action.

There is a difference between both the usages, the first usage just uses a constant called SUCCESS. The later usage has something like !!resultCode?!!, that is the way we use variables to fetch their values. Let us discuss about that in later sections. Let us call those '!!' as variable placeholder. The syntax is similar to PassThrough. The first cell is for Action keyword(Value). Second cell holds XPath of the tag and the third cell is for constant, variable, or both.

Prasad Buddha

Figure 22: Sample Test Executions of PassThrough keyword

Figure 23: Examples of value keyword usage in fitnesse script

23


The flow of Value action is similar to flow of PassThrough except for small changes at the end. Once the existence of Cells 2 and 3 is confirmed, and unique tag resolution is successful, there starts the difference between PassThrough and value actions. Value action verifies, if any variable is provided in the

third cell of the same row in the test-table. If a variable is used, the fixture checks if the variable used is already defined using a PassThrough. If the variable is not yet defined, it throws an error. If the variable is found, it replaces the variable with the value of the variable.

Prasad Buddha

Figure 24: Flow of Value Assertion

24


Once the value in the third cell becomes a constant, the fixture compares that constant string with the value inside the tag, if they are equal the assertion passes, or else it displays the actual value and the expected values. If we provide both variable and string in the third cell, it concatenates both after replacing the value of the variable and then treats the cell as a constant.

As long as there are no exceptions, the flow takes the green path as in Figure 24. Any exception will lead to failure of assertion. XPath matching to no tag, or multiple tags also produces a similar kind of error as in PassThrough.

The wiki script syntax for the above two scenarios (one using a constant in the third cell, and other with a variable) will be as shown below…

| |/ / / / | |Value TCRMService TxResponse TxResult ResultCode SUCCESS| |/ / / / |!! ?!!|Value TCRMService TxResponse TxResult ResultCode resultCode

Example screen-shots of the test runs are given below…

3.5 Not Value‘Not Value’ has the exact re

verse behavior of Value action. Everything is same for Not Value and Value action keywords except for just one and only thing, Not value Expects that value in cell 3 of the test table must not be equal to the value found in the tag.

3.6 CountCount is an assertion type of

action that asserts that the number of tags matching with the XPath is equal to an integer value we provide. For example, we can verify if a party has only one Address or three contact methods etc.,

Once Availability of cells 2 and 3 is confirmed, and the XPath in cell 2 is valid, fixture checks if an integer is provided in cell 3, if it finds anything other than integer, even if it is a real number like 1.0 or 2.5, basic fixture crashes. Count then counts the number of tags matching the given

Prasad Buddha

Figure 25: Test runs of Value Assertion

Figure 26: Flow Of Count Assertion

25


XPath and checks if the count is equal to the integer provided in cell 3. If they are not equal, count throws an error and the assertion fails.

You should not even use a variable in cell 3 as long as you use Basic Fixture. The customized fixture can get a value from a variable and can compare if the value inside the variable is an integer. Example usage is given below…

| |/ / // / |2|count TCRMService TxResponse TCRMPersonBObj TCRMPersonNameBObj

The above fitnesse script line checks if the response xml file has only two TCRMPersonNameBObj tags. That tag can be a parent tag or a child tag, count treats both the tags similar. Here is the screen-shot of the example run of a script with count assertion.

Careful not to use any non-integer because if you do, an exception will be thrown and the test run will crash. This problem is fixed in the customized fixture.

3.7 Exists‘Exists’ is an assertion that makes sure that a tag

matching to the XPath exists at least once in the xml. It only checks for the existence of the tag, but does not have anything to do with the value inside it. Therefore, we do not have to provide any other constant or variable. We can easily conclude that we just need two cells to use this action. ‘Exists’ in the first cell and the XPath of the tag in the second cell. Here is the sample use of it.

Exception will be thrown if the XPath is invalid according to rules of XPath.

| |/ / /Exists TCRMService TCRMPersonBObj TCRMPerson|NameBObj

The assertion passes if at least one TCRMPersonNameBObj at the path mentioned in the XPath is found, and it fails

if the tag is not found. Here is an example screen-shot of running fitnesse script with exists keyword.

Prasad Buddha

Figure 28: Flow of Exists Keyword

Figure 27: Test runs of Count Assertion

Figure 29: Test runs of Exists assertion along with some exceptional cases

26


3.8 Not ExistsIt is an exact opposite of Exists keyword. If ‘Exists’ passes, ‘Not Exists’ fails and vice-verse. Not

Exists checks if tag matching the XPath provided does not exist in the xml. It fails even if a single match found in the file. Here is the usage of it…

| |/ / / |not exists TCRMService TCRMPersonBObj TCRMPersonNameBObj

Here is the screen-shot of test run

Before going on to the next section, let us quickly look at some interesting things, all the action keywords are case insensitive. So far, I mentioned as if the fixture is going to throw an exception if the required cell is not provided, there is a little twist to that point, if any cell required is not provided, the last cell in that row will be considered as the required cell. The execution screen-shots for Exists in Figure 29 are an example to this it.

3.9 Variable Placeholder(!!)The name ‘Variable Placeholders’ explains its purpose. They are used to tell fixture that we are

using a variable. Let us look at some examples similar to the examples we have seen while discussing Value assertion. Let us look at this example first..

| |/ / / | |value TCRMResponse TCRMPersonNameBObj GivenNameOne Mat

The above example is very straightforward, check if the GivenNameOne tag is equal to ‘Mat’ or not? It looks simple. However, how do we deal with a scenario that requires us to check if two tags are equal. One alternative is PassThrough one tag into a variable and compare the variable with the other tag. Well, but how do we tell FitNesse, that we are using a variable? You may arrive at the following answer…

| |/ / [1]/ | ?|PassThrough TCRMResponse TCRMPersonNameBObj GivenNameOne firstName| |/ / [2]/ | ?|Value TCRMResponse TCRMPersonNameBObj GivenNameOne firstName

This problem is solved, but what if we have to check some scenario, where second GivenNameOne tag must be equal to the Mr followed by first GivenNameOne tag? You may simply say to use something like MrfirstName?. I guess you might have identified a problem with this kind of usage. In such a case FitNesse may think that ‘MrfirstName?’ as another variable. Therefore, we need to tell the fixture where the variable starts and where the variable ends. That is why we need to use variable placeholders. The solution is to tell fixture where a variable starts and where a variable ends. We use ‘!!’ for that purpose, precede and succeed the variable with !!. Therefore, this is what we have to do to use a variable…

| |/ / / |!! ?!!|Value TCRMResponse TCRMPersonNameBObj GivenNameOne firstName

This solves our previous problem. This is how we do it.| |/ / / | !! ?!!|Value TCRMResponse TCRMPersonNameBObj GivenNameOne Mr firstName

Now let us look at another example where this variable placeholder will be useful. Say we have a scenario, where in, we have to add a person in the database, and in the next step, we have to retrieve that person from the database. To retrieve a person, we have to use the party id (a unique identifier party in WCC database) that is generated by WCC while adding the party. We have to store the pass the value from response of addPerson to the request of getPerson, without stopping the execution of test script. So how do we change the party id in the request xml. Our variable placeholder will be useful here also. We create the

Prasad Buddha

Figure 30: Test run of Not Exists assertion

27


variable from party id tag in the response of addPerson and use the variable placeholder for this purpose passing it to next request xml file. Look at an example xml file below…

< >TCRMService< />RequestControl< >TCRMInquiry

< > </ >InquiryType getPerson InquiryType< >InquiryParam

< =" ">!! ?!!</ >tcrmParam name partyID partyID tcrmParam< =“ >3</ >tcrmParam name inquiryLevel” tcrmParam

</ >InquiryParam </ >TCRMInquiry</ > TCRMService

See the line with bold characters, the variable ‘partyID?’ is enclosed in double exclamations inside xml file, the fixture will replace ‘!!partyID?!!’ with the value in the variable ‘partyID?’, if it is declared before calling this xml file. The replacement will take place whenever we call the xml file in a fitnesse script. An exception will be thrown if the variable inside the xml file is not defined by the time the file is called in a test table.

3.10 LimitationsWe hate to have limitations. When there are too many, it becomes unusable. This is exactly what

happened with this basic WccXMLFixture, you might have observed that I mentioned about saving files in Figure 2. The image does not show the flow with basic WccXMLFixture, it is for the customized fixture. To know what we cannot do with the basic fixture, just go through the following details.

3.10.1) Strict Adherence to data – Scripts have to be data specificThe basic WccXMLFixture requires the scripts to be written specific to data. Say, we have to use

PassThrough action. If we try to pass-through value of a tag that is not there in the xml, it will produce the error: No Tag Found. You may think that it is correct behavior, and that is what you may expect. However, according to the automation principles, the data and scripts have to be separate, the script should be able to work with wide range of data.

Let me tell you an example why the scripts should not be data specific. Let us assume an optional tag in our xml file. We have to PassThrough that tag into a variable, it is OK if we write a PassThrough action and mention the XPath and the variable name. That script works well as long as the tag exists in the xml and the tag has a value, what if tomorrow, if that optional tag should be removed from xml, do not you think that all our scripts are going to break? Another point is that script will only work with that xml file, if we want to reuse that script to test another xml, we may have to do some modifications and then use it. Therefore, the result is, we cannot create something like reusable components easily if use the basic WccXMLFixture.

We need a better way of PassThrough and Value actions that will intelligently switch their behaviors, depending upon whether a tag exists or not. We have count assertion but we have to provide a constant integer in the script, but generally, that number may change from according to situation, we should be able to compare it with a variable integer. This is missing from basic fixture.

3.10.2) Limited ways of assertingWe have a PassThrough and five assertions in our basic fixture. However, in a real testing environ

ment, we have a lot many things to do, we should be able to check if the dates are past, or future, or cur

Prasad Buddha

28


rent date. We should be able to compare dates in two tags. We should be able to check if a tag is empty or not, we should be able to create variables conditionally.

If you have observed, PassThrough will only provide one way to create a variable from value of a tag. However, if we have to create a variable without any tag, we cannot do that. If we want to copy value of a variable to another variable, we cannot do that. If we want to conditionally pass-through and conditionally compare, we cannot do that. Adding two integers or concatenate two strings is next to impossible. We cannot store count of tags matching to an XPath. Sometimes we may want to check if all the tags matching to a particular XPath has same value or not, we cannot do that because that number need not be a constant or may be large. We have to use value action 100 times, if we have 100 tags of same XPath that we have to compare.

We cannot check if the expected string is a part of value of tag. We cannot check for the length of characters in a string, if required. We cannot pass-through partial value of a tag. The value action is case sensitive, so in case we have to compare the values where the case changes from input to output, we are ahead of a wall. We cannot write comments in the middle of a test script table.

3.10.3) Request and Response xml files not getting savedThis is one of the biggest drawbacks, the request and response xml files are not saved, and

everything is on the fly. They will be printed in the output console as shown in Figure 13, that page must be saved as a HTML and nothing more. However, we may need to have the xml files stored for back referencing or as proofs.

3.10.4) Only responses can be asserted and validatedHere is another funny restriction, you can do those assertions only on response xml files. If you

want to pass-through a tag in request xml file, you are at a total loss. You only got one file to work with and that is response, if you have to compare the tag in request with the tag in response, you do not have a way to do that.

3.10.5) Improper Handling of ExceptionsThere are number of scenarios, where an exception is thrown and the test run is stopped, one such

example is with count, if you do not provide an integer in the third cell, the test will simply crash and the test run stops. There are many such simple issues, which will cause the test run to crash. Good automation scripts will always take about such unexpected scenarios. However, you cannot write such good automation script if you want to write it to the basic version of the WccXMLFixture.

Prasad Buddha

29


3.11 Example TestThe most complex we can get to with the basic WccXMLFixture is, execute a transaction and pick

some tags from the response xml and store them in several variables and execute some other transactions and compare them with some other tags and check count of tags and check if the tags exist. Let us assume an imaginary test case with the following steps.

1. Add a person with a name and birth date using addPerson OOTB transaction2. Retrieve the person details using getPerson3. Compare the name between the response of addPerson and response of getPerson4. Add a new name to the person5. Retrieve the person again6. Check if the party has two names in the response7. Check if the party has a birth date and does not have a deceased date in the response

If you are not aware of WCC OOTB transactions (ready-made transactions available in WCC), we use addPerson OOTB to add individual parties, getPerson is the OOTB transaction to retrieve person details. updatePersonName is an OOTB transaction to add a name to the party.

In our test case, we have four request xml files to send to WCC. addPerson is the first xml request to send to WCC to add that party, then getPerson to retrieve person details. updatePersonName to add a new name to that party is the third and finally getPerson to confirm about count of names and existence of deceased date is the fourth request xml file.

Now, we concluded about number of request xml files; we need four XMLs for this test case. We need same number of test-tables in our test script. Each table sends a request xml file to WCC, and gets the response. Whatever we want to do on that response xml file, like passing through values from tags, and asserting has to be included in the same test-table. According to our test case, we have to compare names, so we have to pass through name tags. We have to retrieve the person so, we have to pass through party id into a variable in the first table. We have to use the variable in the request xml files of getPerson and the updatePersonName. As we have to handle any response xml file in the same test table where the request xml is called, the comparison between names should be dealt in second test table because we already stored the values of the name tags in response xml file of addPerson in the first test table. We do not have anything to do with the response xml file of updatePersonName except checking whether the transaction failed or passed. The fourth and final test table is for retrieving the person details and asserting for the number of names the party has and asserting that birth date exists and deceased date does not exist. Well enough of this theory let us get started with real script. Refer the illustration Syntax for Basic WccXMLFixture for the syntax.

Let us make some assumptions here before going into the script… WCC location is iiop://127.0.0.1:2810 The xml files are stored at location C:\FitNesse\InputXMLs\ There is no instance name defined for WCC server

Let us also check if each service is success or not by checking ResultCode in addition to all the points discussed above. The xml structure is as defined by the OOTB services. Let us only concentrate on GivenNameOne and LastName of TCRMPersonNameBObj, to avoid too lengthy script. As discussed before each table starts with ‘!|’ and ends with an empty line.

For this script to work properly, you should also modify your xml files. For GetPerson.xml to retrieve the person details you should use the variable defined from PartyId tag in the request xml files as explained in section 3.9 Variable Placeholder(!!) . You should also use the same variable in the request of UpdatePersonName.xml also to add a name to that party. I am not going to explain how WCC OOTB services work. Here is the script for all that is explained…

Prasad Buddha

30


!| . . . . |com ibm wcc fitnesse WccXMLFixture|| ://127.0.0.1:2810|iiop| :\ \ \ . |C FitNesse InputXMLs AddPerson xml| |/ / / / | |Value TCRMService TxResponse TxResult ResultCode SUCCESS| |/ // / | ?|PassThrough TCRMService TCRMPersonNameBObj GivenNameOne GivenNameOne| |// / / | ?|PassThrough TCRMPersonBObj TCRMPersonNameBObj LastName LastName| |/ / / / / | ?|PassThrough TCRMService TxResponse ResponseObject TCRMPersonBObj PartyId PartyId

!| . . . . |com ibm wcc fitnesse WccXMLFixture|| ://127.0.0.1:2810|iiop| :\ \ \ 1. |C FitNesse InputXMLs GetPerson xml| |/ / / / | |Value TCRMService TxResponse TxResult ResultCode SUCCESS| |// / / |!! ?!!|Value TCRMPersonBObj TCRMPersonNameBObj GivenNameOne GivenNameOne| |// / / |!! ?!!|Value TCRMPersonBObj TCRMPersonNameBObj LastName LastName

!| . . . . |com ibm wcc fitnesse WccXMLFixture|| ://127.0.0.1:2810|iiop| :\ \ \ . |C FitNesse InputXMLs UpdatePersonName xml| |/ / / / | |Value TCRMService TxResponse TxResult ResultCode SUCCESS

!| . . . . |com ibm wcc fitnesse WccXMLFixture|| ://127.0.0.1:2810|iiop| :\ \ \ 2. |C FitNesse InputXMLs GetPerson xml| |/ / / / | |Value TCRMService TxResponse TxResult ResultCode SUCCESS| |/ / / / / |Not Exists TCRMService TxResponse ResponseObject TCRMPersonBObj DeceasedDate| |/ / / / / |Exists TCRMService TxResponse ResponseObject TCRMPersonBObj BirthDate| |/ / / / / |2|Count TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPersonNameBObj

If you have observed, the first three lines are same in all the four test tables, except for the file names. The fourth line in all the test-tables has a value action that verifies if the value in the ResultCode is ‘SUCCESS’. The first table has three PassThrough actions, one each for GivenNameOne, LastName and PartyId. Please note that the ‘?’ at the end of each variable is just a convention, it is not mandatory. If you have observed, the PartyId PassThrough row is after the GivenNameOne and LastName variable definitions. If you are aware of the xml structure of response of addPerson transaction, you know that the PartyId tag comes before the other two tags. You do not have to follow the order in which the tags appear in the xml file.

Second table checks the value of GivenNameOne and LastName tags if they are equal to the variables defined. Third table just sends the request to WCC and checks if the result code is SUCCESS. Fourth table verifies that the response xml file does not have DeceasedDate and has BirthDate with the help of Not Exists and Exists assertions. The last line with count assertion checks if the response has two TCRMPersonNameBObjs.

Before we close the discussion about basic fixture, make a note of several points. You can define same variable any number of times. However, the variable will retain the latest value passed into it. It is not mandatory to use any variable after it is defined. You cannot use a variable in any action or request xml until it is defined. For example, as the ‘PartyId?’ is defined in the first table, you cannot use !!PartyId?!! in the request AddPerson.xml, because by the time fixture deals with the request, it still does not have the response xml to define the ‘PartyId?’ variable. You can also use a variable in XPath if required after the variable is defined (e.g. //TCRMPersonNameBObj[LastName = '!!LastName?!!']/GivenNameOne ). You can use any complex XPath as long as it is valid as per the rules defined in XPath 2.0.

Prasad Buddha

31


4.4.Customized FixtureCustomized FixtureThe previous chapter introduced you to the features of the fundamental fixture. The same chapter

also explained what could not be done with it. We came a long way from a point where we decided that the fixture cannot be used for real testing to this point, where we automated nearly 4000 test cases. As I explained you before that WccXMLFixture is a small program written in java. The fixture code used to be mere 200 lines. It has grown to vast 4000 lines of code with all my customizations. The basic structure of the fixture is modified in a lot many ways. As the time progresses, new challenges came up, I had to keep on adding new functionality to solve those automation problems. At this point of time, the fixture has a lot more functionality. We designed a very efficient way of testing xml transactions using all the new functionality. Let us go one-step at a time from defining the types of customizations to very detailed explanation of all the customizations. However, this document does not tell you how to create fixtures or how to customize WccXMLFixture. It only helps you learn all the new functionality and how to use them.

Here is a list of the modifications to the fixture… Syntax changes Behavioral modifications New passthroughs New assertions File handlers Miscellaneous action keywords Variable placeholders Predefined variables

4.1 New SyntaxTo provide more functionality, not everything can be done in with the same syntax of the test

tables. So the test table is redesigned to accommodate new functionality. This new syntax is carefully designed in such a way that none of the existing scripts break, along with giving provision to the new functionality. Therefore, it is compatible with the existing scripts. Here is the new syntax for the advanced or customized WccXMLFixture.

Instead of just Cell 3 in the test table from fourth row as shown in Illustration 1: Syntax for BasicWccXMLFixture, we can now use cells 3, 4, 5, 6. However, they are conditional. Number of cells required changes from action to action. Only one action keyword requires up to cell 6. We will take a detailed look at new action keywords later. To allow various file handling mechanisms, a new optional cell is introduced in the third row. If you ignore the file handler cell, the xml file name cell will be the first cell. If you provide file handler keyword and provide the xml file name in the second cell in the same row, given file handling method will be opted. We discuss about file handlers and new action keywords in the subsequent sections. All the cells given in Grey are optional according to the new syntax rules of test-table.

Prasad Buddha

Illustration 2: Syntax for customized fixture

com.ibm.wcc.fitnesse.WccXMLFixtureWCC Instance Name WCC Provider URLFile Handler XML file nameAction Keyword XPath of the tag to be used from response XML Cell 3 Cell 4 Cell 5 Cell 6

Action Keyword XPath of the tag to be used from response XML Cell 3 Cell 4 Cell 5 Cell 6

::

32


4.2 Behavioral ModificationsThe Customizations started right from the way fixture behaves. We mentioned two limitations for

the basic fixture. The basic fixture does not save files, the customized fixture does.

4.2.1) Storing request and response xml filesWccXMLFixture takes a request file mentioned in the script. If there are any variables (like !!

PartyId?!!) in the request, fixture replaces them with their values and saves that file in a folder named request next to the original request xml file. It then sends this new request xml file to WCC, gets the response, and saves the response file in another folder named response next to the original request file. If the request and response folders do not exist, fixture will create them. The request file stored inside request folder will have the same name as the original file. However, the response file stored in response folder will have an additional ‘Response_’ appended at the beginning of the file name. So, name of the response xml file for AddPerson.xml will be ‘Response_AddPerson.xml’.

Initially, I have designed it to overwrite the existing request and response xml files. Then the behavior is modified again, so that you control if it overwrites the existing files or takes backup of old files. Now, the files will be over written by default. This behavior can be modified by changing the value of a predefined variable ‘?CreateBackup?’. If the value stored inside the ‘?CreateBackup?’ variable is ‘yes’, then backup files will be created for the existing request and response xml files. If the value inside that variable is ‘no’, then the fixture will overwrite the existing request and response xml files.

When we change the value of the create backup variable to ‘yes’, a new folder with the name old will be created in both request and response folders. If the fixture has to overwrite a file in the request or response folder, it will move the existing file to old folder after appending last updated dates of the existing files to their names. New file will be created in request or response folders. By appending last updated dates before copying into old folders, any number of historical copies can be maintained for record.

If you observe, there are two copies of each response file in old folder. It is because the test is run twice and backups are maintained each time the test is run. Observe the time stamps to get a clearer picture. The Latest copies of request and response files will be maintained inside the request and response folders and all the old files will be inside old folders. We discuss more about this variable and modifying its value later.

Prasad Buddha

Figure 32: Before executing test Figure 31: After executing test

Figure 33: Response files created in response folder

Figure 34: Backups of response files inside old folder

33


4.2.2) XPath validations on Request xml As mentioned earlier the basic fixture can only do validations on response xml file, any action on

request xml file tag produces the error: Tag not found, unless that XPath accidentally matches with a tag in response xml file. With the new fixture, you do not have to do anything new except for using the XPath from request xml directly. Let me tell you how this functionality is implemented. The fixture does not know anything about xml structures, it takes XPath and tries it on one of the files (either request or response). If the XPath does not match to any tag in the request file, instead of throwing an error, fixture goes to response file for XPath validation. Therefore, we got double work to do, though it is not significant for a single XPath validation, the number of assertions in a test case can grow to a very large number depending on the complexity of the test case. We have several test cases where we have more than 1000 assertions in many test cases. We have to follow a better approach than this trial and error approach.

For our project, in fact, for any xml project, generally the xml structures will be constant at lower depth (root tag has a depth of zero and its children has a depth of one and so the depth increases). Therefore, all the XPath for request xml file will have a common start point. The same is the case with XPath for response xml files. For WCC, the XPath for request will start with either /TCRMService/RequestControl, or /TCRMService/TCRMTx, or /TCRMService/TCRMInquiry. We call these request markers, because if the provided XPath starts with any of these, it means that the XPath belongs to request. The same logic is used to decide whether the XPath belongs to request or response. However, hard coding the request markers in code will reduce the flexibility, if we have to have some other request markers, we may not be able to do that unless we modify the code.

Therefore, I decided to go with a properties file in which these request markers are defined. Properties file is created after you run a test using the advanced WccXMLFixture for the first time. The name of the properties file is ‘properties.xml’. The tag <RequestMarker/> will hold the request XPath portions. If you want to add additional request markers, you just add another RequestMarker tag with the request marking XPath portion. If your project has request xml structure that always starts with /A/B/C then you add another RequestMarker tag as below…

< >/ / / </ >RequestMarker A B C RequestMarker

RequestMarker XPath is case insensitive. So, it will not be a problem, even if you provide /a/b/c. Our project has two different applications with which FitNesse interacts, WCC and WQS. The request markers for both WQS and WCC can be found in the properties.xml snippet in section Properties File.

4.2.3) Output CapturedAs displayed in Figure 13, the output logs have all the xml files placed one after another. This is

not so convenient when it comes to verifying something from the logs. So, the way FitNesse captures output log is also modified. Instead of displaying the entire xml, the new design just displays a hyperlink to the xml file as in Figure 35. Clicking on that link will display the xml file in the browser as in Figure 36. This avoids clutter as well as reduces the length of the output logging. We can easily debug because it will be easy to read xml in a browser with color-coding rather than just a plain text as in Figure 13.

If you have noticed, there are two sections in the output log. Each section represents output log for one test table. Where did three files come from? Read the text before the hyperlink once again. When we click a test button, one input file will be taken from the file system and then all the fitnesse variables in the file will be replaced and a new request file will be prepared by the fixture. It sends that modified request to WCC and gets a response. That is why there are three hyperlinks in each group. One link is for request file before variable replace and another for request file after variables are replaced and finally one more hyperlink for the response.

To achieve this new logging mechanism, WccXMLFixture makes use of the functionality provided by FitNesse. FitNesse provides an opportunity to refer an external file through the wiki script if it is stored

Prasad Buddha

34


in ‘files’ folder inside FitNesseRoot folder. WccXMLFixture creates a new folder called XmlTemp inside files folder and stores all the request and response xml files in it and prints the hyperlink while running the tests. However, in order for this to work, you should place all DTD files in XmlTemp, XmlTemp\request and XmlTemp\response folder. Or else the browser will not be able to display the xml file and throws an error.

Prasad Buddha

Figure 36: Once an xml file hyperlink is clicked, it will be opened in browser window

Figure 35: Output logging redesigned.

35


4.2.4) Properties FileAs discussed in the previous section, properties file provide a way to differentiate between the re

quest and response using RequestMarker tag. The properties.xml has many other tags, which change the way the fixture behaves. Let us look at the complete properties.xml at its current state.

The PerformanceTest tag should be Y if Performance Testing is to be enabled< >WccFitNesseProperties

< > . </ >DevelopedBy JSSVPrasad Buddha DevelopedBy< >1.8</ >Version VersionDate format used by Fixture for asserting dates< > - - </ >DateFormat yyyy MM dd DateFormat< >/ / </ >ResponseMarker TCRMService TxResponse ResponseMarker< >/ / </ >ResponseMarker TCRMService ResponseControl ResponseMarker< >/ : / : </ >ResponseMarker soapenv Envelope soapenv Body ResponseMarker

Response xml file All the Request XPath should have one of the Request Marker

< >/ / </ >RequestMarker TCRMService RequestControl RequestMarker< >/ / </ >RequestMarker TCRMService TCRMTx RequestMarker< >/ / </ >RequestMarker TCRMService TCRMInquiry RequestMarker< >/ : </ >RequestMarker soap addressStandardization RequestMarker< >/ : </ >RequestMarker soap addressValidation RequestMarker< >/ : </ >RequestMarker soap nameStandardization RequestMarker

UniqueNumber This value increases every time you click Test or Suite

< >01325</ >UniqueNumber UniqueNumber

if service time is crossed than the threshold< >/ / / </ResponseTimeTagXPath TCRMService ResponseControl ServiceTime ResponseTimeTagX

>Path< >5000</ >ResponseTimeThreshold ResponseTimeThreshold< > </ >PerformanceTestEnabled N PerformanceTestEnabled

</ >WccFitNesseProperties

There are several RequestMarker tags some of them are for WQS testing where we will be sending the SOAP requests to WQS. The ResponseMarker tags are initially used for differentiating between request XPath and response XPath, but later I found that using RequestMarker would be more useful than ResponseMarker. There can be some scenarios where the XPath does not contain both the markers (e.g. //GivenNameOne) that can be from request as well as response. In such an ambiguous situation, the fixture assumes that this XPath belongs to response. To make this assumption easy in code the decision is taken to use RequestMarker instead of ResponseMarker.

Prasad Buddha

36


The other tag in the properties file is DateFormat. This can be changed if you want any other date format for some action keywords like Is Before, Is After etc., The date format may change from implementation to implementation in WCC as WCC provides flexibility to change the date format. The default format given in the properties file is yyyy-MM-dd because this is the date format, we use in our project. You can give any format like yyyy MMM dd hh:mm:ss. Later we will discuss about the action keywords, which make use of this DateFormat.

The Version tag is to keep track of the version of the properties file. If there is an updated version of WccXMLFixture, the properties file is updated according to the new code. When you run a test on new WccXMLFixture, it finds out if the properties file is of the old version. If the version is less than the current version it replaces the properties file with the new file as defined in the WccXMLFixture code.

UniqueNumber is the tag that contains an integer. It increments every time a test is run, or whenever we reset the predefined variables in the script. Resetting the predefined variables is something that we are going to deal a bit later in this document. This integer can grow to any large number starting from one if you keep on running the tests. You can change the value inside UniqueNumber tag and the value will be incremented from that number. Using this UniqueNumber variable will be explained in section ?UniqueNumber? .

4.2.5) Testing the performanceThe last three tags of properties file are for

doing a small scale performance testing. If we have any common threshold for service time for all the services, we can enable the performance testing and can give the threshold limit for service time in milli seconds. We can enable the performance testing by setting PerformanceTestEnabled tag to Y.

Whenever the service time crosses the threshold limit, the fixture will warn you about that by changing color of the cell, in which the service time is displayed, to be yellow. Everything else works just the way it used to work. The threshold limit must be provided in milli seconds in the tag ResponseTimeThreshold.

For WCC, the service time will be populated in ServiceTime tag always, in case your implementation has any other tag to get the service time from, provide its XPath.

This is the current version of properties file. I am going to add new features to the fixture, for which, I may need to add some more tags to the properties file. One final and funny thing about properties.xml is, it is designed in such a way that the order of xml tags does not matter. You can modify order of the tags inside properties file, but do not change the content in the tags unless you know what you are doing.

Prasad Buddha

Figure 37: Service Time will be displayed when Performance Testing is enabled

Figure 38: Whenever service time of a service time crosses the threshold limit, it will be highlighted

37


4.2.6) Action Keyword behavioral changesSeveral action keywords are updated with new code such that they behave in a slightly different

way. PassThrough, Value, Exists and Not Exists are not modified much except to also consider XPath from a request. The major change is with Count. Observe the following Script and its output and see if you can find out the reason for failure.

When we run the above script, we get an exception and test run crashes as shown in following figure. The exception causes the test run to stop suddenly, and we do not see any clue why it failed. Did you guess what is wrong? The last line in the above script is the culprit. We have given ‘Two’ instead of an integer in the third cell. This may look like a small problem, which could be found in a minute. Imagine that you have 200 lines of script, and it failed suddenly with an exception. Finding the exact location and reason of the problem is tough. The customized fixture handles this in a better manner. Here is the screen-shot of the same script running with my fixture.

This instantly shows you where the problem is without crashing. Another advancement in count action is, you can also use variables if required. You can use the variable as you have used with value assertion. Just make sure that there is an integer in that variable or else an exception is thrown. Of course, that exception will be caught by the new fixture before the test can crash.

Prasad Buddha

Figure 39: An Example script with a small fault

Figure 40: Execution result when we run the above script. Test run is crashed. Can you guess what's wrong?

Figure 41: Exception handling for count in customized fixture

38


4.3 File HandlersAnother such customization is with the way fixture handles the request xml files. Several file

handling mechanisms are added to the fixture, to provide flexibility to the way fixture handle the request files. We do not have to send the request file to WCC every time. We may need to access the response files that are already created as a part of the same or some other test case, without sending it to WCC. You might have recognized that we do not have any means of just reading an xml file without sending it to WCC in basic fixture.

The customized fixture handles it by introducing file handler keywords and modifying the syntax of the fitnesse script in the third row as displayed in the figure.

ByPass Pass Force Optional No File

Let us take a closer look at the each file handler keyword a bit later.

4.3.1) ByPassUsing any file handler is very simple. It must be used as shown below…

| | :\ \ . |ByPass C Xmls addPerson xml

The concept of ByPass is also very easy, whenever you mention ByPass file handler before a file name, fixture avoids sending that request to WCC. It uses that file just for doing actions mentioned from the fourth line onwards. The same file is considered as a request and response as well.

Observe the figure to understand more about the ByPass file handler. WCC is on a distant island without any interaction from FitNesse and there is no response xml file.

Why do we need file handler that does not send the xml file to WCC? Let us say we want to deal with a response xml file repeatedly, instead of sending the request multiple times, we can send the request

Prasad Buddha

Figure 43: ByPass file handler

Figure 42: File Handler Cell in test table

39


once to WCC, and we can call response xml multiple times using this ByPass file handler. This saves us from repeatedly sending the same request to WCC to get the response.

4.3.2) PassPass works just as default file handler, it sends request file to WCC normally look at the Figure 2

Interactions between User, FitNesse, Fixture and WCC to look at the way default file handler works. It normally sends the request to WCC and receives the response. Well, why do we need one more thing that does exactly same as an existing thing?

Let us assume a scenario where we have 100 test cases, and we have a test step in all of them, like adding a party, that can be executed only once in WCC server and the test cases may have to be executed more than once. For example, say we can add a party in each test case only once and our test cases work if that party is added to the database once. We cannot add the party for the second time even if we run the test case for second time. How do we deal with such a scenario? One solution is saving all the steps that must be executed only once in a separate suite and all other steps in another suite. This works as long as the adding the party for each test case is the first step, but what if the party has to be added as part of second test table? This where a combination of Pass, ByPass and page-variables come to use. Did you get how to do it?

Instead of hard coding Pass or ByPass, we use a fitnesse page-variable, in all our test tables, which have to be run only once, as below.

| { }| :\ \ . |$ ByPassOrPass C XMLs addPerson xml

We have to define that page-variable in the parent suite page for all the test cases with either ByPass or Pass. To run all the steps for the first time, we have to provide value Pass in the variable. Before running the same test cases again, change the value in the variable to ‘ByPass’. Now from second time onwards, addPerson will be by-passed and party will not be added again. The reason for doing this is, we can modify the contents of a cell using these variables, but we cannot add new cells. ByPass can be made into Pass and Pass can be made into ByPass, but default file handler cannot be converted to other file handler, as there is no cell for default file handler.

4.3.3) ForceObserve Figure 44. If

you read the error message, it says that variable ‘partyID?’ cannot be found from previous test run. This PassThrough problem will come when an undefined variable is used in an xml file for a default file handler. This may look like a valid scenario because when some variable is not filled in request xml, there is a high probability that WCC may throw error, because if party id is mandatory for transaction like getPerson.

Nevertheless, it is not true all the times. There will be some optional fields as GivenNameTwo in updatePersonName transaction. In such a scenario, it is not mandatory to throw this exception. Anyway, the fixture does not always have to worry about the missing variables because WCC will obviously throw error, if it is a mandatory field. So this Force file handler is introduced to handle such optional variables, which may not be necessary to be defined.

Prasad Buddha

Figure 44: PassThrough exception is thrown when an undefined variable is used in the xml file

40


This is what Force does, whenever it finds a variable, which is not previously defined, it replaces that variable with an empty string.

< >TCRMService< >TCRMInquiry


< =“ >!! ?!!</ >tcrmParam name partyID” partyID tcrmParam< =“ >3</ >tcrmParam name inquiryLevel” tcrmParam

</ >InquiryParam</ >TCRMInquiry

</ >TCRMService

The above xml be converted as below when the variable ‘partyID?’ is not defined before. The request shown below will be sent to WCC, of course, this xml will result into an error from WCC, party-id is mandatory for getPerson transaction.

< >TCRMService< >TCRMInquiry


< =“ ></ >tcrmParam name partyID” tcrmParam< =“ >3</ >tcrmParam name inquiryLevel” tcrmParam

</ >InquiryParam</ >TCRMInquiry

</ >TCRMService

Syntax of force file handler is as shown below…| | :\ \ . |Force C XMLs addPerson xml

4.3.4) OptionalAs discussed in the previous

section, the force will push the xml to WCC at any cost, by replacing the undefined variables with an empty string. However, ‘Optional’ file handler has two different types of behaviors. It behaves like a ByPass whenever a variable is not found in the xml file and works like Pass when all the variables used in a request are found.

See the screen shots provided, the first picture is a scenario where the variable is defined. Optional file handler is used on getPerson.xml in which the variable ‘partyID?’ is used. The variable ‘partyID?’ is defined in the first test table. Therefore, the optional keyword just behaved as Pass and ResultCode exists in the response of getPerson transaction.

Prasad Buddha

Figure 45: Optional just working as Pass as the variable partyID? is defined

41


If you observe the second picture, the same script is run, however with a small modification. Instead of the variable name ‘partyID?’ the variable is defined as ‘CONT_ID?’. However, the request of getPerson is not modified and it still has !!partyID?!!. Now, the Optional file handler behaved as ByPass and did not send the getPerson.xml to WCC. That is the reason why the ResultCode is not found. If you remember, with ByPass the request itself is considered as the response. As the request does not have the tag ResultCode, the Exists assertion failed with an error: Tag Not Found. Here is the syntax of Optional file handler…

| | :\ \ . |Optional C XMLs addPerson xml

4.3.5) No FileSometimes we want to create tables without any xml file. It may be for performing some miscel

laneous operations like add, copy, variable assignments etc., without any interference with xml tags. Below is the example of ‘No File’ file handler.

Forget about what is CCopy and others, all you have to worry about is that there is no file name mentioned in the third row and the word ‘no file’ is mentioned instead.

Prasad Buddha

Figure 46: Optional behaving as ByPass because partyID? variable used in getPerson is not found

Figure 47: Example of 'no file' file handler

42


4.4 Predefined Variables Generally, we cannot add same test data repeatedly to the database. For example, if DSP set to ON

in WCC server, we cannot run same addPerson request xml file twice. We should be able to randomize the input. It leads to a conclusion that we need some unique data to be created by the fixture for us, to use it in request xml files or actions. That is why predefined variables are created. Here is the list of predefined variables as of now…

?UniqueKey? ?UniqueNumber? ?YYYY? ?MM? ?DD? ?CreateBackup?

Why is there question mark before and after all the variables? This is just a convention to differentiate between a variable created in test script and a predefined variable.

4.4.1) ?UniqueKey?'?UniqueKey?' is a predefined variable which is an alphanumeric string. This will be unique every

time we run a new test or new suite. However, when we run several test cases as a suite, the value in the unique key variable will be same for all the tests. The fixture is designed in such a way that it creates the variable when we click the test button or suite button.

You can use this variable like any other variable you created using passthrough actions. Either in xml files or in a test script, you have to use it inside variable placeholders. How does it create a unique string every time? To be precise, it does not create a new unique string every time, however, it creates a new string for every one second. The algorithm used for generating a unique string is as follows. The fixture takes start date as July 22nd 2008 and counts number of seconds that paused until now. However, we cannot use that number as it is, because it will be very big number, we need around 5-8 characters or else it may cause problems because of its length. The fixture then converts that large number is a 32 base number from decimal number. This converts that large number into a 6-character string as of now. The length is going to be six until around 2040, so we do not have to worry change in its length. The value coming out of this unique key variable is similar to 1A89B0.

4.4.2) ?UniqueNumber?We have to use ‘?UniqueNumber?’ variable if we want to place a unique number in the xml file

while executing. It generates a minimum of six digits. It increases each time we execute a test case or test suite. So, if there are ten test cases in a test suite and when we execute all the test cases as suite, the value in the variable ‘?UniqueNumber?’ is going to be same for all ten test cases. If you want to change the value in this variable, you will have to use Reset All. The convention we are following in our assignment is, we have a ‘Reset All’ action at the end of each test script.

Generating a unique number is tough. Unlike UniqueKey (which is alphanumeric), unique number variable is a numeric value. Therefore, there are only 10 digits, hence we cannot generate it using the time difference. Because if we do so, just for ten days the number will be 864000 and in 100 days it will become a 7 digit number. In 3 years, the length will be eight. You expect six digits in a tag and use this variable, but it will become a seven-digit number in 100 days, which may cause unexpected failures.Therefore, it is not safe to depend on it.

I decided to use a different approach that is using the properties file for this. If you remember, the tag UniqueNumber holds an integer, whenever a test is initiated, the number from the tag is taken and

Prasad Buddha

43


stored in the variable '?UniqueNumber?' and the integer in the UniqueNumber tag of properties file is incremented. Therefore, we can guarantee the uniqueness of the value inside the variable ?UniqueNumber?.

However, even with this algorithm, length changes quickly. If we assume that we run a test every 10 seconds, it will take 3 years for us to 7 digits, but how are going to handle length of the UniqueNumber initially? It adds zeroes in the beginning of the number until six digits. So it starts with filling 000001 in place of !!?UniqueNumber?!!, and keeps on increasing. To reset the value, you can simply change the value in properties file (remember the UniqueNumber tag?) and the unique numbers will start from the number you provide.

4.4.3) ?YYYY?, ?MM?, ?DD?'?YYYY?' variable has current year in YYYY format. '?MM?' has month in two digit format and '?

DD?' in two digit date format. These three variables can be used in combination to produce date in several formats. In our assignment the date format is yyyy-MM-dd, we will have to pass current system dated in the request xml files in some cases. So we got to use ‘!!?YYYY?!!-!!?MM?!!-!!?DD?!!’ or ‘##?YYYY?##-##?MM?##-##?DD?##’ where ever we want to replace with current system date. I will explain about ## variable placeholder later.

4.4.4) ?CreateBackup?‘?CreateBackup?’ is not just a regular variable. This is a behavioral modifier of the fixture. It is a

property that you can change. It can have two values either ‘yes’ or ‘no’. If the value inside this variable is ‘yes’, fixture creates backup copies of a request and a response xml files in old folder. If it has ‘no’ in it, existing request and response files will be overwritten and the backup copies are not stored. Refer to the section Storing request and response xml files about backing up of files while executing tests. You can change the variable like any other variable using copy or some other means, which are explained in sections New Passthroughs and Miscellaneous Key words. You can also change the value in the middle of a test script.

Prasad Buddha

44


4.5 New Variable PlaceholderAs you know, ‘!!’ is a variable placeholder that helps us to replace a variable with its value. ‘!!’ re

places the variable with the exact value. I have added a new variable placeholder to the fixture, let us discuss about that now.

4.5.1) ##This is a new variable placeholder that converts the value of the variable into uppercase and then

replaces the variable with the converted value. Here is the example screenshot of test runs with ## variable placeholder.

Observe the difference between the first row and second row as !!two?!! resulted into Middle Name and value assertion passed which means !! is replacing the value exactly as it is in the variable. The second row ##two?## is converted into MIDDLE NAME and the value assertion failed. Observe the expected and actual values for the action keyword.

The same is the case even with using ## in xml files. Therefore, if we assume that the value in a variable ‘two?’ is ‘middle name’. <GivenNameOne>##two?##</GivenNameOne> in the request will become <GivenNameOne>MIDDLE NAME</GivenNameOne> before going to WCC.

Prasad Buddha

Figure 48: !! Versus ##

45


4.6 New PassthroughsIn the basic fixture PassThrough is the only action for storing a value from a tag in a variable. We

need more ways of storing value from tag, and we need flexible ways that react to complicated scenarios and dynamic test data environments. We need to store partial values of a tag. We need to store count of XPath. Here is the list of new pass-through actions.

Count PassThrough Part PassThrough CPassThrough CPart PassThrough CPassThrough Or Copy

Lets us look at one by one, from easiest to the slightly complex.

4.6.1) Count PassThroughThis action stores the number of tags matching the XPath in a variable. If the tag does not exist in

the xml file, the Count PassThrough will store zero in the variable. The syntax is similar to PassThrough.| |/ / / / /Count PassThrough TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPerson

[ =‘ ]| ?|NameBObj LastName Jones’ nameCount

4.6.2) Part PassThroughNow let us move to another kind of PassThrough. This is a shortened form of Partial PassThrough.

As the full form says, Part PassThrough helps us store partial values of a tag into a variable. When we store using PassThrough, the entire value inside the tag is stored in the variable. However, with Part PassThrough, we can precisely control from which character to which character, we want to extract from the tag and store in a variable.

To be able to control the start point and endpoint in a string, I have defined three additional parameters in Cell 4, Cell 5, and Cell 6. Here is the syntax for Part PassThrough…

You know the first three cells. The fourth cell is for mentioning the starting character in the string the index starts from one not from zero. The fifth cell is for the endpoint and the sixth cell is for length. To pinpoint a portion of a string precisely, you have two ways to do that, mention either start point to endpoint or endpoint and length. When a start point is provided, the fixture ignores the length. Otherwise, length becomes mandatory.

| |// / / | ?|3|5|Part PassThrough TCRMPersonBObj TCRMPersonNameBObj GivenNameOne name

The previous syntax line will extract from third character to fifth character from the GivenNameOne tag. Isn’t it simple? Try to answer this. How will you tell fixture to extract from 3rd character to the last character? It is impossible to do it with whatever I explained you so far, because you will never know what the length of the string is (at least not always). So, little more functionality is added to the Part PassThrough action. The way to do it is, you give any number larger than the number of characters in the

Prasad Buddha

Illustration 3: Syntax of Part PassThrough action keywordPart PassThrough XPath of the tag to be used Variable Name Start Point End Point Length

Figure 49: Count PassThrough test run

46


string like 999999. Then the Part PassThrough will reduce the given endpoint to the real endpoint of the string(length of the string). This is how it looks like in the fitnesse script…

| |// / / | ?|3|99999|Part PassThrough TCRMPersonBObj TCRMPersonNameBObj GivenNameOne name

You may get a doubt why the length parameter is provided. Can’t we just tell the start point and endpoint to extract portion of the string? You can, but how are you going to tell a fixture to pick last four characters when we do not know the number of characters in the string. This length parameter is provided to solve that problem. We use end-length pattern of Part PassThrough to pick last n number of characters of a string. Let us look at an example of end-length pattern. In this end-length pattern, we mention the endpoint of the portion you want to extract from the string and number of characters you want to extract. If you want to extract last four characters of a string of length10 characters, you should provide endpoint as 10 and length as four. The syntax is as below…

| |// / / | ?||10|4|Part PassThrough TCRMPersonBObj TCRMPersonNameBObj GivenNameOne name

Then how to pick the last four characters of a string, when the number of characters in the string is unknown? The answer is similar, instead of providing the actual endpoint, we will provide something like 99999. Here is the answer…

| |// / / | ?||99999|4|Part PassThrough TCRMPersonBObj TCRMPersonNameBObj GivenNameOne name

Make a note of an empty cell provided instead of start point, if you do not provide that empty cell then 99999 will be the fourth cell and will be considered as a start point and 4 will be considered as endpoint. If you provide a start point, which is greater than endpoint, this will reset the start point to make it equal to the endpoint. If length is greater than endpoint, it will also be reduced to endpoint. Here is the screen-shot of Part PassThrough run.

In the above example, to make it easy to understand, I provided 123456789 in the requesterName tag. If the tag is not found or if more than one tag is found, the Part PassThrough will throw an error.

Prasad Buddha

Figure 50: Test execution with various combinations of start, end and lengths

47


4.6.3) CPassThroughI should say this is one of the three most significant changes to the fixture. It revolutionized the

way we write automation scripts. The other two significant changes are ByPass and CValue IgnoreCase. These three features drastically reduced the time needed to create automation scripts and debug them. Even though the concept of CPassThrough is very simple, but when we used it along with CValue IgnoreCase it is a wonder. It took me nearly a week to design these features and develop them in the fixture. We saved nearly two person months in a span of one month i.e., we would have nearly spent three months to do the same work if we have to do it without CPassThrough, CValue IgnoreCase and ByPass. Half of the time saved by them is directly saved because of these features and the remaining half of the time saved by them indirectly. I mean, they paved a way to take a new approach called Re-usability. It saved us hell a lot of time. The reasons why I could come up with this new approach are simply the above three mentioned. Without these three, there is no concept of Re-usability.

The expanded form of CPassThrough is Conditional PassThrough. It conditionally decides whether to create a variable or not. The difference between PassThrough and CPassThrough is simple, if no tag is found for CPassThrough, it does not throw any error it simply ignores that row in the test table. It also ignores the row in the test table if no value is found in the tag.

However, CPassThrough still requires a valid XPath and that should match to one and only one tag. If the XPath is invalid, it must be corrected. If more than one tag is found for the XPath, fixture cannot decide, which tag to store the value from. You may get a doubt why that scenario can not be ignored. Let me explain you the whole theory behind creating CPassThrough and CValue IgnoreCase. When both are used one a same tag in a script, if the tag does not have a value before it most probably won’t have the value afterward, so if variable is not defined before it won’t the CValue IgnoreCase expects that tag to be empty. If the variable is defined, CValue IgnoreCase expects that the tag to have a same value. So, if more than one tag is found for the XPath, CPassThrough throws error because if it just ignores that line and the CValue IgnoreCase does not find the variable and expects the tag to be empty. However, we have the value in one or more tags.

Let me rephrase the above scenario in practical terms, if the person has GivenNameTwo while adding the party, the getPerson will also have that tag. If the person is added without GivenNameTwo in the name, the getPerson will also do not have the tag. However, if there are more than one GivenNameTwo tags, the getPerson will also have values in GivenNameTwo tags, so the right thing to do is to throw an error instead of just ignoring the action keyword. Here is the syntax of CPassThrough…

| |// / / | ?|CPassThrough TCRMPersonBObj TCRMPersonNameBObj GivenNameOne name

The examples for passed, failed and ignored scenarios are provided in Figure 52.

Prasad Buddha

Figure 51: Flow of CPassThrough

48


Observe the third and fourth CPassThrough in the above screen-shot. If you observe third cells in both the rows, they are in gray color, it is a way of showing that the rows are just ignored without any error. If you observe the messages in the second cells of both the rows, you will understand why each CPassThrough failed. First message is Tag Not Found for XPath and the second message is No Value inside tag. Do they need more explanations? I suppose not.

4.6.4) CPart PassThroughCPart PassThrough is a mixture of both Part PassThrough and CPassThrough. As you know,

CPassThrough ignores the action row if the tag is not found, and defines a variable if the tag with a value inside it is found. Part PassThrough defines the variable with a partial value inside it. However, if the tag is not found, Part PassThrough will throw an error. We are unable to write conditional action rows that are common for number of scripts. We lost the flexibility, the scripts have to be data specific.

However, we recently got requirement to write a common script with Part PassThrough, that works for number of xml files. Part PassThrough is not conditional, and if the tag that is referred by its XPath is not found in the xml file, that action is going to throw an error. This means that we cannot use this action for tags that are optional and may not be present in xml file. Therefore, I have added this new pass-through kind of action. Unlike Part PassThrough, CPart PassThrough will not throw an error if the tags are not found. This will simply ignore the action row. If the tag is found, it simply works like a Part PassThrough.

Prasad Buddha

Figure 52: Test runs of CPassThrough in various scenario

Illustration 4: Syntax of CPart PassThrough action keyword; Exactly like Part PassThroughCpart PassThrough XPath of the tag to be used Variable Name Start Point End Point Length

49


4.6.5) CPassThrough Or CopyThis is slightly complicated than

CPassThrough, in fact, it is an extension to CPassThrough. There will be many scenarios where some default values will be assigned when we do not provide the tag or leave the tag blank. How do we deal with such a scenario? ‘CPassThrough Or Copy’ solves one special scenario of this problem. We have other ways to solve the remaining problems. Let us look at what CPassThrough Or Copy does…

It checks if a unique tag is found for XPath, and if it does, it will create the variable and copy the value from the tag into the variable. However, if it does not find a tag, it tries to fetch the value from fourth cell, if a variable is found in cell 4, it checks if the variable is already defined. If the variable is not found, the action line is ignored and if the variable is found, it replaces the variable with the value in the variable and copies that final string into a newly created variable.

However, if the tag is empty, then it just ignores the action without considering cell 4. If more than one tag is found, it is an error.

Prasad Buddha

Figure 53: Flow of CPassThrough Or Copy action keyword

Figure 54: Test runs of CPassThrough Or Copy

50


Fourth cell can be a variable or a constant or combination of both. It is same as third cell in value assertion. The variable has to be enclosed in variable placeholders as usual. Here is the syntax of CPassThrough Or Copy…

This action is widely used in testing update services. Let us say you are updating the name of a person who has a name with the elements GivenNameOne, GivenNameTwo, LastName. If you try to update the name, and if you provide an empty tag for GivenNameTwo in updatePersonName request xml file, then the GivenNameTwo will be deleted from the person’s name. However, if you do not provide the tag in the request, then the existing value for the GivenNameTwo will be persisted.

This is the exact reason for which CPassThrough or Copy is designed. We mention the XPath of the tag, which we want to store the value of, and provide a variable name and in the fourth cell, we give the variable defined for the value of same tag previous variable. So, if the request xml has no value in that tag, the value in the old variable will be ignored, that is what WCC does, it deletes the value in the tag. If tag is not found, the old variable value will be copied into the new variable. WCC retains the value of that tag if there is any before update transaction.

4.7 New AssertionsSo far, we discussed about the new pass-through kind of actions. Let us move on to the new

assertions. Following is the list of assertions I have added so far. Value IgnoreCase Contains Is Empty Not Empty Length Is PastDate Is FutureDate Is Today Is Before Is After Is SameDate CValue CValue IgnoreCase CContains All CValue IgnoreCase All CContains

4.7.1) Value IgnoreCaseThis assertion works the same way as Value assertion, but it will compare without considering the

case. So, Hello and hello are equal for this assertion. It fails if the data in the tag is not equal to the specified value, even after ignoring the case. Check the screen-shot below…

Prasad Buddha

Illustration 5: Syntax for CPassThrough Or CopyCpassThrough Or Copy XPath of the tag to be used Variable Name String With Or Without Variable

Figure 55: Test runs of Value IgnoreCase

51


4.7.2) ContainsSo far, you have seen comparison of entire value inside a tag with another tag. ‘Contains’ checks

if the expected value (value in cell3) is inside the actual value (value of the tag). It also ignores the case. There is no difference between flow of value assertion (Figure 24) and contains assertion except for the last step, where it also passes if the expected value is inside the actual value (value inside tag). Syntax of Contains assertion is similar to Value assertion.

| |/ / /*/ / |## ?##|Contains TCRMService TxResponse TCRMPersonNameBObj GivenNameTwo two

First six rows of Contains assertions in Figure 56 are as expected, but sixth and last one is a bit tricky. Isn’t the ‘Middle Name’ a partial value of ‘Middle Name meddle’? Yes it is. However, contains checks if expected value is inside actual value i.e. it checks if ‘Middle Name meddle’ is inside ‘Middle Name’. In this scenario, actual value is a part of expected value. If you observe third Contains assertion, you can find that Contains also matched, even if the expected and actual values are equal.

4.7.3) Is Empty‘Is Empty’ assertion checks if a tag exists, but is empty.

If there is a value in the tag, the assertion fails. The assertion also fails when the tag is not found or the XPath is invalid.

‘Is Empty’ also fails when more than one tag is found for the XPath. Look at the above screen-shot for different scenarios.

4.7.4) Not Empty‘Not empty’ is exact opposite of Is Empty. It works ex

actly the same way except at the last step. Is Empty checks if the tag empty, where as Not Empty checks if the tag is not empty. Otherwise, the assertion fails.

Prasad Buddha

Figure 56: Test runs of Contains assertion

Figure 57: Flow of IsEmpty

Figure 58: Test runs of Is Empty assertion

52


4.7.5) LengthLength Assertion checks if the number of characters in a tag is as expected. Here is the syntax for

Length assertion in Illustration 6…

This assertion can be useful if there is a scenario where in WCC have to auto generate some keys of specific number of digits. Here are test runs of Length assertion.

If you look at the last assertion, it still needs more clarity. For many errors, it only says Problem with XPath. It throws the same error message even for an XPath, which matches to more than one tag. I shall be fixing it in later version of the fixture.

4.7.6) Is PastDateThe assertions we looked at so far considers

the value in the tag as either a string or an integer. However, that may not be enough all the times. Sometimes, we will have to work with dates. Now let us discuss about some date assertions. First one of this kind is Is PastDate. This assertion checks if the tag has a past date. It compares against the current system date. It will only check against dates, it will not consider the time on which the assertion is tested.

If the tag has a value ‘2009-10-10 00:00:00’, and if we tested when the time is ‘2009-10-10 13:45:00’, assertion fails. It is because the date in the tag is same as the current date.

I have created a dummy xml file with different dates so that testing will be easy. Observe the screen shot in Figure 60 to understand how the Is PastDate assertion works. That dummy xml contains several tags with different dates. The PastDate tag has a past date in it, Future date has a future date, RepeatedDate tag is repeated more than once etc.,

As I said Is PastDate compares value inside a tag with current system date, so we do not have to provide any other dates we compare with. So, Is PastDate only requires two cells, Action keyword cell and XPath cell.

4.7.7) Is FutureDate‘Is FutureDate’ also works like ‘Is PastDate’ except that it checks if the tag has a future date.

Look at the Figure 64 to see how it works. The error messages also changed for Is future Date assertion.

Prasad Buddha

Illustration 6: Syntax of Length AssertionLength XPath Number Of Characters

Figure 59: Test runs of Length assertion

Figure 60: Test runs of Is PastDate

53


4.7.8) Is Today‘Is Today’ is an assertion that checks if the tag has a current system date. This assertion fails if the

tag does not have the current system date. Look at the Figure 63 for test run examples.

Prasad Buddha

Figure 61: Test runs of Is PastDate Figure 62: Test runs of Is PastDate

Figure 63: Test runs of Is Today

54


4.7.9) Is BeforeThe previous three assertions work with

current system date and the tag. Sometimes we may have to compare a tag with another tag. In such a scenario, ‘Is Before’ and the next two assertions do the trick. Is Before checks the date inside a tag with a variable or constant. It asserts that the date inside the tag is before the date provided in Cell 3.

Figure 66: Test runs of Is Before assertion

The cell 3 can be either a variable or a constant. Here is the example usage | |/ / |2009-06-08|Is Before DateTestXML PastDate

If you remember, we have discussed about DateFormat tag in properties.xml file. Is Before, Is After, Is SameDate will use the date format provided in that tag. So, if your implementation of WCC uses

Prasad Buddha

Figure 64: Test runs of Is Future Date

Figure 65: Test runs of Is Future Date

55


any date format other than yyyy-MM-dd, you have to mention that date format in the tag DateFormat in properties.xml.

4.7.10) Is After‘Is After’ action checks if the date inside a tag is after the date provided in the cell 3. There is no

difference between Is Before and Is After as long as the syntax is considered, Screenshots of test runs for Is After assertion is in Figure 67.

4.7.11) Is SameDate‘Is SameDate’ checks if the value inside a tag is same date as the provided in the cell 3. Here are

the test runs of Is SameDate assertion. Everything else is same as the Is Before and Is After assertions.

Prasad Buddha

Figure 67: Test runs of IS After assertion

Figure 68: Test runs of Is SameDate assertion

56


4.7.12) CValue

Prasad Buddha

Figure 69: Flow of CValue assertion

57


This is an advanced version of Value assertion, CValue means Conditional Value. The same way CPassThrough decides whether to ignore the assertion, or pass or fail the assertion, CValue conditionally decides.

Observe the flow chart in Figure 69. Do not worry. It looks big and complex, but it is not that tough to understand. The concept is simple, if a variable is defined before, it means that there is a value inside tag while defining it, so the tag must also have the same value now. If the tag is missing or value inside tag blank or is different while comparing, there is something wrong because the variable is defined before. If a variable is not defined, either the value in the tag is empty while defining the variable or the tag is missing while using CPassThrough on that tag. So, either there must be no tag or the tag must be blank even while comparing. If a non-empty tag is found while comparing, where did that value come from? There must be something wrong. If variable and tag are not found that is OK, just ignore that. To achieve this effect, we try to use CPassThrough to define the variables, on which we want to use CValue.

If more than one tag is found at any point of time, it is an error. There must only one tag found when the variable used in cell 3 is already defined or else fixture cannot decide on which tag to work with, so this one is also an error. That is it. The whole logic of the entire flowchart is in Figure 69.

To get maximum benefit out of it, you should use CValue along with CPassThrough. I meant to create the variable using CPassThrough and compare them with tags using CValue. You can also define

Prasad Buddha

Figure 70: All tags present with PassThrough and Value assertions

58


the same variable with PassThrough and compare it with CValue. Hmm, you may ask me how the combination of CPassThrough and CValue is going to be useful. Let us look at an example and compare it with PassThrough and Value, then you will find an obvious difference. Let us assume that there is a person being added to the WCC, and we have to compare his name from addPerson request to getPerson response xml. Here is how you write a fitnesse script using a PassThrough and Value.

The previous screen-shot may be giving you a false sense of security that everything went right, and it is perfect. Yes, you are right everything went right, but it is not perfect. What if tomorrow the ad

dPerson xml is modified because of some reason? Let us say GivenNameThree tag is made empty and GivenNameFour is deleted. See the screen-shot of another test run after making the mentioned changes in Figure 71.

Oops, the script has broken. Is there anything wrong with the way addPerson and getPerson working? The answer is No. This is what we do not want from any automation script, we do not want attention when we do not have anything wrong. The GivenNameThree and GivenNameFour are not added while adding the party, so there is nothing wrong, even if we ignore them while comparing. So, moral of the story is that if you want to modify xml file, you should also check if your fitnesse script is broken, and if it

Prasad Buddha

Figure 71: Test run of PassThrough and Value combination after removing tags

59


did, you should modify the script also. You cannot use the same script for some other test cases where GivenNameTwo is also missing.

Let us use CValue instead of Value. Look at the Figure 72, for the screen-shot with the Value replaced with CValue. As we did not have the values while adding the party, PassThrough did not create the variables. As the variables used in Cell 3 are not defined by PassThrough in first test table, CValue

checked if any tags with the XPath provided in cell 2 are found as the response of getPerson does not have any tags without values, the CValue simple ignored that action row in the test table. You can see the messages that variable not found and tag not found for XPath the same rows.

However, as you can clearly see from the Figure 72, the problem is not completely fixed. Even though things went right in getPerson test table, not everything looks right in test table 1. PassThrough throws an error whenever you want to PassThrough an empty or missing tag. So, we cannot use PassThrough when the xml file is tend to change. The other alternative we have is CPassThrough.

Observe Figure 73 to see how CPassThrough and CValue’s combination have adjusted itself to ignore when some tags are missing. Observe test run examples of CValue. The first example is straight. Second CValue failed because there is a value in GivenNameTwo tag in request (I have used same request xml and same pass through actions as used in Figure 73 and Figure 72) but the variable ‘undefVariable?’ is

Prasad Buddha

Figure 72: Using CValue didn't completely fix that problem; PassThrough still creates a problem

60


never defined before. As a result, it failed. The last two assertions failed because more than one tag is found for comparison. This is it, did you sense the flexibility you got while using CPassThrough and CValue. This is why CPassThrough and CValue are one of the best features, I added to the fixture.

4.7.13) CValue IgnoreCaseCValue IgnoreCase is same as CValue except that it ignores the case while comparison. So, I do

not I have to re-explain this assertion. Syntax is similar except the action keyword to be used. For this assertion, the keyword is CValue IgnoreCase.

4.7.14) CContainsDo you remember what ‘Contains’ does? It just checks the same way but conditionally as CValue

IgnoreCase does. Here are the test run examples of CContains.

Prasad Buddha

Figure 73: Everything is fixed using CPassThrough and CValue

61


Observe that CContains failed because we appended ‘Mr.’ before the variable making the expected value Mr.Indiana, where as the actual just has the value Indiana. Do not forget that Contains and CContains checks if the expected value is inside actual value.

4.7.15) All CValue IgnoreCaseAll CValue IgnoreCase and All CContains assertions are different from other assertions in a way

that these two work on more than one tag. All CValue IgnoreCase, is conditional as CValue IgnoreCase. However, the CValue IgnoreCase fails if more than one tag is found but All CValue IgnoreCase compares all the matching tags and fails if even one comparison fails. Let us say we have to test searchPerson OOTB transaction. Our test case is, we have to search using identification number, and we have to check if all the parties returned in the response of the searchPerson has same identification number. How do we do that? We simply use All CValue IgnoreCase, and we give an XPath that matches to all the identification numbers in the xml and we give the value to which it should be equal. That’s it. This is how our assertion looks when we do not run it ..

Prasad Buddha

Figure 74: Test runs of CContains

Figure 75: Test runs of CValue

62


Once we run, it turns to something like this…

Observe last two cells in All CValue IgnoreCase test run, it is saying 12345678901 != 12345678903 in the last but one line and all the rows above it said all those tags match with the value provided in cell 3.

If we use a variable in cell three, the variable will be replaced with its value as usual, and comparison will be done with all the tags as shown in Figure 78. If the variable is not found, but values found in the tags matching to that XPath, it is an error as in Figure 79.

4.7.16) All CContainsThis is similar to All CValue IgnoreCase except that it checks if the expected value is inside the

value in all the tags. Observe the below screen-shots and you will understand everything you have to understand.

If you have observed the last row in first All CContains in Figure 80, it is saying 34567890 is not in 78901 because the variable has larger string than actual value. The second assertion is where the XPath is matching to only one tag, observe the difference between the first XPath and second XPath we have additionally used [1] to restrict the XPath to first TCRMOrganizationSearchResultBObj. When only one tag is matched to the XPath, there will not be any difference between CContains and All CContains.

Prasad Buddha

Figure 76: Example syntax of All CValue IgnoreCase

Figure 77: Test run of All CValue IgnoreCase with an XPath matching more than one tag

Figure 78: All tags matching with the variable value

Figure 79: Conditional failure with All CValue IgnoreCase

63


The conditional failures are also same as other conditional assertions, does not deserve any separate mention over here again.

4.8 Miscellaneous Key words We have seen several action keywords so far, but there is a common point between everything dis

cussed so far. They all work on one or multiple tags. Of course, in the context of WCC xml testing, that may seem sufficient, but there will be several scenarios where we may have to do something other than just working with tag even when testing XMLs. Probably, we may want to check if number of TCRMPersonNameBObj is increased by one if we add a new name using addPersonName transaction. We may want to define our own variable without any interference of a tag. We may want to be reminded of some manual comparison etc. Several miscellaneous keywords are added to the fixture. They will answer all the above questions. Let us look at all of them one by one. Here is the list of all the miscellaneous keywords…

Copy CCopy Add If Variable Exists … EndIf Display Value Display Count Exception Remind Reset Reset All #

4.8.1) CopyCopy acts like a PassThrough but there will not be any need for a tag. We can create a variable us

ing a constant or a variable enclosed in variable placeholder. It simply copies a constant or value inside a variable into a new variable. Once a variable is created, there will not be any difference between the variable created by it and the variables created by PassThrough keywords. Look at the Figure 81 to find out how to create a variable using copy.

Figure 81: Example of Copying a constant value into a variable

Prasad Buddha

Figure 80: Test runs of All CContains

64


As in Figure 82, if you give two variables or two constants or any number of entities(variables or constants) in the second cells both values will be concatenated and copied into variable. Copy assertion fails if a variable used in cell 2 is undefined as in the last row of the figure.

4.8.2) CCopyCCopy is a conditional action. If we do not want the error to be thrown if any variable used in cell

2 is not defined beforehand, just ignore that line, we use Conditional Copy in short CCopy. Nothing much is there to explain, here is the screen-shot of CCopy execution.

There are three things to observe from this screen-shot. One: you do not have to worry about the case of action keyword, observe that I have given each row in a mixed case, this is also applicable to any action keyword. Two: if a variable is not found as in seventh row, the action line is ignored by CCopy, however, copy will throw an error in such a scenario. Three: if you use the same variable multiple times, the old value will be removed and new value will be stored in the variable. Four, if you do not provide third cell, a new variable for which the variable name and value inside variable are equal. Observe Dummy stringBuddha = Dummy stringBuddha in last but one row, this is also applicable to copy. Five if you provide an empty third cell, an error will be thrown as in the last row of screen-shot of CCopy, the same is applicable to copy also.

Prasad Buddha

Figure 82: Test runs of Copy

Figure 83: Test runs of CCopy

65


4.8.3) AddThis is another miscellaneous action keyword

that actually adds two integers or two strings and stores them in a new variable. However, if you accidentally give a string in any of the cells in which you have to give integers, both will be treated as strings. If both are integers they will be added, if they are strings, they will be concatenated.

So, in total, we need four cells for Add keyword. Syntax of Add action keyword is provided in Illustration 7.

You can provide anything in cell 2 and cell 3. All the variables will be replaced with their values if the variables are provided inside variable placeholders. If the final values in both the cells are integers then an integer addition will take place. If one of them is string or a real number with some decimal places, then both will be treated as string and will be concatenated.

Refer Figure 84 for examples of test runs of add. You can clearly see when Integer addition occurred and when string concatenation occurred. If we miss any cell, it will throw an error.

4.8.4) If Variable Exists … EndIfIf Variable Exists … EndIf is not a single keyword. If

… EndIf is a conditional block and variable exists is one such assertion that works for If. If … EndIf is designed to provide a conditional execution of several statements. We are creating variables conditionally, so sometimes we may have to find out if a variable is already defined. ‘Variable Exists’ assertion checks if a variable is already defined. However, ‘Variable Exists’ cannot work on its own, we have to use it along with If action keyword. Let us look at the syntax of If … EndIf first, and then we will see the syntax of If Variable Exists … EndIf.

‘If’ action needs an assertion keyword that should result into either true or false. Depending on whether that assertion keyword results into true or false, if action decides whether to run action lines or not. If assertion keyword results into true, it executes all action lines until EndIf. If it results into false, it skips the action lines until EndIf. Assertion Keyword requires some elements to results into true or false. However, as of now, there is only one if assertion keyword i.e., Variable Exists. Variable Exists checks if a variable is already defined, so, it needs only one assertion element to result into true or

Prasad Buddha

Figure 84: Test runs of Add Keyword

Illustration 9: Syntax of If Variable Exists … EndIf action keyword

If Variable Exists Variable nameAction Line

Action LineEndIf

::

Illustration 8: Syntax of If … EndIf action keyword

If If assertion Keyword If assertion elementsAction Line

Action LineEndIf

::

Illustration 7: Syntax of Add action keywordAdd variable or constant variable or constant variable name

66


false. We have to provide the name of the variable in the third cell. Action Lines between If and EndIf can be normal rows as in a test table.

Now, here is the syntax of If Variable Exists … EndIf. The first cell of the first row of If … EndIf block should be ‘If’ as any other action keyword. The second cell in the first row is the action keyword, in this case, it should be Variable Exists. The third cell is for the name of the variable, which we should check if it is defined or not. From the second line of If … EndIf block, the action lines and to mention the end of the conditional block you have to provide EndIf. Look at these examples in Figure 85. The wiki script for the screen-shot is also provided.

| { } \ . |$ WCCInputDirBase Samples addPerson xml| |123| ?|Copy var| | | ?|If Variable Exists var| |/ / /*/*/ | ?|Exists TCRMService TxResponse PartyId partyID| |/ / // / | |Value TCRMService TxResponse TCRMPersonNameBObj GivenNameOne Indiana| |/ / // / | |Value TCRMService TxResponse TCRMPersonNameBObj GivenNameTwo Ind| |EndIf| | | ?|If Variable Exists undefinedVar| |/ / // / | |Value TCRMService TxResponse TCRMPersonNameBObj GivenNameOne Indiana| |/ / // / | |Value TCRMService TxResponse TCRMPersonNameBObj GivenNameTwo Ind| |EndIf

There are two If blocks in this script. First block is with a defined variable. Observe that the action lines are run as the variable ‘var?’ is defined. They behave normally as ever. Observe that second assertion failed because. If you observe the second If Variable Exists … EndIf block, you can see that the variable ‘undefinedVar?’ is not defined before and so the action lines in that conditional block are skipped.

4.8.5) Display ValueDisplay Value is an

action keyword that is added to the fixture to display values inside the tag without doing some PassThrough. This is just for display purposes. Here is an example…

Display Value returns an error if the tag is not found or if the tag is empty. It also throws an exception in the test run so that the tester will get an attention, and the test report band too will turn into yellow as in Figure 15.

Prasad Buddha

Figure 85: Test runs of If Variable Exists ... EndIf

Figure 86: Test runs of Display Value

67


4.8.6) Display CountDisplay Count displays the number of tags match

ing the XPath. Display Count also throws assertions. Check Figure 87.

4.8.7) ExceptionThis simply throws an exception to alert of

something the tester wants to be alerted. A comment can be added to the Exception. Check Figure 88.

4.8.8) RemindSame as exception, no difference at all, except for the action keyword. Check Figure 88.

4.8.9) ## is for providing com

ments in the middle of a test table. The fixture simply ignores the line in which the action keyword in #. The Cell will remain Grey when we run the test. Comment can have any number of cells based on need.

4.8.10) ResetSo far, we have seen different action

keywords that create or use a variable. Reset and Reset All are different from everything else. They are terminators. Reset will remove all the variables that are defined using PassThrough action keywords and Miscellaneous Keywords. If there is any predefined variable, they will not be disturbed at all.

The syntax is simply a one-cell row with reset in the cell. Observe the screen-shot first.

If you observe the value in the variable '?UniqueKey?' is 1M9NGA, and is copied into a variable ‘var?’. If … EndIf does not skip the Remind action line as the variable ‘var?’ is defined. However, if you observe the reset keyword, it says ‘Variables Map is Reset’. If you observe the second If block skipped Remind action line, because the ‘var?’ is destroyed. If you check the second copy line ?UniqueKey? Still has the same 1M9NGA. As evident from the Figure 90 Reset will not reset predefined variables. We generally insert Reset at the end of a script.

Prasad Buddha

Figure 88: Test runs of Exception and Remind

Figure 90: Test runs of reset

Figure 89: Observe that the line above exists is ignored without any action

Figure 87: Test runs of Display Count

68


4.8.11) Reset AllThe Reset All is a kind of extension to

Reset. It resets the entire variable set and resets the predefined variables. Observe that variable ‘?UniqueKey?’ is also changed after reset all, the initial value in Unique Key is 1MAFQ0 where as the value after reset all is 1MAFQ4. A new unique key will be generated with the same logic as discussed. Unique number variable will be incremented by one.

4.9 Advantages of Customized fixtureThe fixture is customized to cover the limitations from the basic fixture. To list all the advantages

is very easy. Let us have a glance at the advantages one more time.

4.9.1) Separating scripts from dataYou have seen, how CPassThrough and CValue have saved our day in Figure 73. Now we can use

the same portion of script forgetting about what may miss in the xml file, when prefix comes blank or suffix tag is not found in the xml. The script still works. This is what I call as separating scripts from data. This is one of the fundamental principles of automation. Change in data should not cause the automation script to fail. The basic fixture fails with any such change where as the actions in customized fixture adjust themselves depending on the data.

Therefore, we can call these scripts “Flexible scripts”. These scripts can handle changes in data almost all the times. There can be some limited scenarios where this flexibility can let some defects escape. Let us say, that the addPerson transaction should fail when we do not provide a value in GivenNameThree tag. However, because of some defect in the code, the transaction got executed successfully. Even in such case our test case passes, because CPassThrough will ignore the GivenNameThree tag while creating the variable and even in getPerson transaction response xml, we do not get the GivenNameThree tag so CValue does not throw any error.

Hmm, now it looks like too much flexibility can cause some damage. However, one thing we are forgetting is an automation script should not do more than what test case does. If we really want to test whether the addPerson fails when we do not pass a GivenNameThree. There must be a test case which is testing just that. The test case must expect a FATAL result code in response when a blank GivenNameThree is passed. But what if you do not want to write the test case, and want to verify in the same automation script? Just use Value instead of CValue while asserting the value of GivenNameThree in the getPerson response in the second test table. So, Value assertion will throw an error as shown in Figure 92.

Prasad Buddha

Figure 91: Test runs of Reset All

69


4.9.2) More ActionsAs you have already seen, there are only six actions in Basic Fixture. Only one way of passing

through the value from a tag either you pass entire value or do not. With the new actions, you have number of ways to extract value from a tag. You can extract partial values, decide whether to create a variable or not at run time. You can store the count. The same is the case with assertions. You can even assert dates. There are many miscellaneous keywords added to let you create your own variables. You can write comments within the test table. All these new actions have paved way for designing a new approach called Re-usability.

Prasad Buddha

Figure 92: By mixing the assertions of basic fixture and new fixture can yield best results

Figure 93: Difference between old WccXMLFixture and current WccXMLFixture because of customizations

70


All these new actions opened the doors for testing complicated requirements. Even some actions are taken from existing fixture, some of them are updated to handle some of the exceptions that used to crash the test run without letting us test anymore. Most of such crashes are caught now so that we can run the test continuously without much fuss.

4.9.3) Request as well as response xml files can be validatedOne of the biggest problems with the basic fixture is it cannot assert on request xml tags. If you

want to compare from a request to its response, you are at nowhere. With this customized fixture, you can do validations on any file you want and the best part is, you do not have to mention which is request XPath and which is response XPath. Based on the XPath you provide, it judges whether you want to work with the request or the response, and acts accordingly.

4.9.4) Requests and Responses getting saved for future referenceAs I have already explained, modified request and response xml files are saved in the same loca

tion where the original xml file is located. It also creates the backup files while overwriting if you choose so by changing the value in ‘?CreateBackup?’ variable to ‘Yes’. By default, the value inside this variable is ‘No’. Therefore, the default behavior is to overwrite the existing request and response files.

Basic fixture cannot save these files. It just displays them in Output Captured window. You have to save that page in HTML format with the old fixture.

4.9.5) Unique Key generators and Unique Number generators and several other predefined variables

We generally need some unique data in every automation project. With the new predefined variables like ‘?UniqueNumber?’, ‘?UniqueKey?’ you can get unique data. You can use these variables anywhere, just as any other variable defined via fitnesse script.

Other predefined variables like ‘?YYYY?’, ‘?MM?’, ‘?DD?’ can be used to generate date kind of data based on current system date. The reason for giving three different variables is, they can be used to achieve any kind of format.

4.9.6) Customized log makes it easy to open xml files for debuggingAs I have explained in 4.2.3) Output Captured the output logging in the customized fixture not only

looks good, but also reduces the load on FitNesse as it does not have to print all the files to the log. Opening xml files in browser with colors will make finding some data easy, especially when the xml file is big.

You can also see the xml before replacing with variables and after variable replace so that we can debug some more problems that can come by using wrong variables in xml.

Prasad Buddha

71


5.5.Re-usabilityRe-usabilityUntil now, I have just discussed about linear way of creating scripts. If you have used any automa

tion tool before, you will still see one missing feature, Re-usability. We cannot just prepare automation scripts for hundreds of scripts in a linear fashion. One small change in the requirements or missing portion of scripts will leave you in front of a heap of changes to be done on all your scripts. When we are testing applications like WCC, MDM, we will find that we need to create similar portions of scripts repeatedly. We need a better approach than just linear way of creating fitnesse scripts.

In any automation framework, we will generally create some reusable components and use those components to achieve the logic of the test case. In order to be able to do that way, we have to separate the scripts from data. The same script component should work for different sets of data. Maybe not for all sets of data, but the component should at least work for wide varieties of data. With the new actions and features, we can think of using the same components for multiple scripts. I have designed a new methodology to create fitnesse scripts in our project by using the new features I have added and the features provided by FitNesse. Let me explain you how it is done in our project.

FitNesse by default provides a functionality called ‘Page in lining’. Using this feature, we can include one page in another. This is the base for our entire methodology. Here is an example for including a page in Figure 94. The figure has two things. One: there are two test tables. Two: one of the test tables looks different. There is a border around the first test table. It is an example of Page in lining.

We can include a page in another page using the following syntax…! < >include Path of the page to be included

FitNesse uses ‘!include’ to include a page. The path can be either relative or absolute. An absolute path must start with a ‘.’ and should include from the top most page. I have marked an area on the figure with a red ellipse. It shows the path of the component included in the current script. The path says ReusableComponents.CisAddParty. There is no ‘.’ at the beginning of the path hence it is a relative party. We can infer that there is a suite named ReusableComponents as a sibling (two pages defined as children for same script are called siblings) of the current script being shown in the figure. Inside the ReusableComponents suite, there is a children page defined with the name CisAddParty and is included in the current script. Look at the raw wiki script to see how it is done.

Prasad Buddha

Figure 94: Page In-lining; or Page inclusion

72


''' : '''!- Test Verify that the MaintainPartyAlias transaction successfully adds a new Alias name to the . . , , party Party has only legal name and the party is an Individual NameType FirstName Middle, , .-!Name LastName Effective Date are provided in the request

----

! .include ReusableComponents CisAddParty

!| . . . . |com ibm wcc fitnesse WccXMLFixture| { }| { }|$ WCCInstanceName $ WCCProviderUrl| | { } \ . |optional $ WCCInputDirBase Samples getPerson xml| |/ / / / |Exists TCRMService TxResponse TxResult ResultCode| |/ / / / | |Value TCRMService TxResponse TxResult ResultCode SUCCESS| |/ / / / / |!! ?!!|Value TCRMService TxResponse ResponseObject TCRMPersonBObj PartyId partyID

Look at the line that starts with !include. It helped us include the page CisAddParty into the current script. Not Everything else is of much importance now. If you go to the CisAddParty component, you will just find a test table that is being shown here nothing else. We can include entire page but we cannot include portion of a page.

In the script of the component, there is nothing new it will be simply as below…!| . . . . |com ibm wcc fitnesse WccXMLFixture| { }| { }|$ WCCInstanceName $ WCCProviderUrl| | { }\ 10001 - . |BYPass $ WCCInputDirBase MPAL a aCISAddParty xml| |/ / / / | |Value TCRMService TxResponse TxResult ResultCode SUCCESS| |/ / / /*/ | ?|Passthrough TCRMService TxResponse ResponseObject PartyId PartyId

Just ignore the variable ‘${WCCInputDirBase}’ it is just a variable to store path. We prepare these portions of scripts, that can be reused, and save them at one location. Later we include these components in the actual test scripts, wherever we need it. So, the steps involved are pretty straight forward. Here they are…

Creating the Reusable Components Using or Including the Reusable Components

5.1 Designing the Reusable ComponentsBefore we can design these, we have to plan. The first thing we need to decide is what must be the

reusable component? In our project we typically planned the reusable components by dividing the components based on BObj (if you are not aware of what is a BObj, this is the terminology we use in xml it is a parent tag for similar elements.) A typical example is creating a reusable component for TCRMPersonNameBObj and all of its children tags.

This can again be divided into two different components. Generally in most of our test cases, we PassThrough the elements of one BObj, and compare all of them again after doing a specific task. To quote an example, we can check whether all the elements of TCRMPersonNameBObj are added into the database properly or not. We achieve it by passing through all elements of TCRMPersonNameBObj from the request of addPerson and then by comparing them in the response of addPerson and getPerson. So, it will be beneficial if we divide passing through and comparing those elements with the defined variables into two different components.

There are several things to be noted before we can build a reusable component. I have just mentioned that we cannot include part of a page. So, we have to build atomic(cannot be broken down) components. They have to be planned in such a way they need not be broken. That is the reason why we have divided passing through and asserting into two different components as just explained.

Prasad Buddha

73


As you can see from the Figure 94, there is a file name in the first test table. Did you get a doubt now? Will not the file name be same if we include the same component in multiple scripts? Yes it will be. If we hard code the file name in the script, it will be same in every script. Therefore, you will have to parameterize (any variable that is declared or created at the time of creating a script is called as page-variable). The same is the case with file handler. It may have to be modified based on the situation as shown below.

!| . . . . |com ibm wcc fitnesse WccXMLFixture| { }| { }|$ WCCInstanceName $ WCCProviderUrl| { }| { }\ { }|$ FileHandler $ WCCInputDirBase $ FileName| |/ / / / | |Value TCRMService TxResponse TxResult ResultCode SUCCESS| |/ / / /*/ | ?|PassThrough TCRMService TxResponse ResponseObject PartyId PartyId

A typical component as we just discussed is to PassThrough all the name elements. If we want to use the same reusable component in two different scripts or twice in a single script, to PassThrough two different names, we cannot hard code the xpath. If we do so, the xpath is going to point same name BObj. We should also use a variable to change the index of the Xpath. The same logic applies for name of the variables also. Each name elements must be stored in a different variable. This is how it can be done…

!| . . . . |com ibm wcc fitnesse WccXMLFixture| { }| { }|$ WCCInstanceName $ WCCProviderUrl| { }| { }\ { }|$ FileHandler $ WCCInputDirBase $ FileName| |/ / / / /CPassThrough TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPersonName

{ }/ | { } ?|BObj$ XpathIndex PrefixType PersonName$ VariableIndex PrefixType| |/ / / / /CPassthrough TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPersonName

{ }/ | { } ?|BObj$ XpathIndex PrefixDescription PersonName$ VariableIndex PrefixDescription| |/ / / / /PassThrough TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPersonName

{ }/ | { } ?|BObj$ XpathIndex GivenNameOne PersonName$ VariableIndex GivenNameOne| |/ / / / /CPassthrough TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPersonName

{ }/ | { } ?|BObj$ XpathIndex GivenNameTwo PersonName$ VariableIndex GivenNameTwo| |/ / / / /CPassthrough TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPersonName

{ }/ | { } ?|BObj$ XpathIndex GivenNameThree PersonName$ VariableIndex GivenNameThree| |/ / / / /CPassthrough TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPersonName

{ }/ | { } ?|BObj$ XpathIndex GivenNameFour PersonName$ VariableIndex GivenNameFour| |/ / / / /PassThrough TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPersonName

{ }/ | { } ?|BObj$ XpathIndex LastName PersonName$ VariableIndex LastName| |/ / / / /CPassthrough TCRMService TxResponse ResponseObject TCRMPersonBObj TCRMPersonName

{ }/ | { } ?|BObj$ XpathIndex Suffix PersonName$ VariableIndex Suffix

Observe the variables XpathIndex and VariableIndex in the above component. If you have some mandatory elements, you have to use PassThrough for such things. So, the errors in the xml file can be caught easily. For all the other optional elements, use CPassthrough, so that they will be ignored if they are not provided in the xml. Once you planned the scripts, all you got to do is plan where to place the scripts. We have created a sibling suite page to all the automation scripts with the name ReusableComponents and created all the ReusableComponents as children to this new suite. So, all the reusable components stay at one location for easy access.

Prasad Buddha

Figure 95: Reusable Components suite page as sibling for other test scripts

74


5.2 Including the Reusable ComponentsNow, since we changed the script to have variables instead of hard coded values, the script in

which it is defined will be having trouble placing the value in place of variable. Where does it get the actual file name to be placed in the script? You face the problem as shown in Figure 96 and Figure 97.

How do we handle this? Simply by defining the variables in the page in which we have to use this component. Observe Figure 98 where the variables are defined before using the reusable component. The values in the variables appear the included component.

We have to do the same thing for all the automation scripts, wherever these components have to be used. This way, the component can be called as a reusable component. Where ever you want to reuse the component, define the variables along with it. You know, how to define variables in fitnesse pages. To define a variable we use ‘!define’ in the raw wiki script. It is already explained in section Syntax for Base Fixture.

Prasad Buddha

Figure 96: Variable defined in the Reusable Component will cause scripts to throw an error undefined variable

Figure 97: A typical component for passing through all the name tags

Figure 98: Variables are defined before using the component where in the variables are used

75


Let us look at it one more time. The syntax for defining a variable is as follows…! < > { }define Variable Name Value

As an example, let us see how the script is written for using (including) a reusable component as in Figure 98. Here is how the script has to be…

! { 10001 - . }define FileName MPAL a aCISAddParty xml! { }define FileHandler Pass! .include ReusableComponents CisAddParty

If we assume that, we have a script where we have to add a party and PassThrough two of his names. The script that uses our reusable components, I have explained so far, should use the CisAddParty component once and PassThrough Name component twice (there are two names to PassThrough, but the component at a time deals with one).

Prasad Buddha

Figure 99: A script that stores values in two name BObjs after adding the party

76


Look at Figure 99. The same reusable component is used for passing through values in tags in two different name BObjs in the same file. Observe that in both the name PassThrough reusable components (it is named as CisRetrievePersonPassthroughOneName in our script, check the screen-shot in the previous figure.) same file is used by setting its FileHandler to be ByPass. The file used by both components that are passing through names is the response file generated in the first component. The files can be used in any way you have to. As we are using ByPass file handler, it is just used for storing the variables. Notice the way XPath and variable name is changed with the help of the variables XpathIndex and VariableIndex in the reusable component. You can define the variable any number of times, the included component will get recent value. The raw wiki script for achieving what is done in Figure 99 should be as below…

! { 10001 - . }define FileName MPAL a aCISAddParty xml! { }define FileHandler Pass! .include ReusableComponents CisAddParty

! { \ _ 10001 - . }define FileName response Response MPAL a aCISAddParty xml! { }define FileHandler ByPass! {[1]}define XpathIndex! {[1]}define VariableIndex! .include ReusableComponents CisRetrievePersonPassthroughOneName

! { \ _ 10001 - . }define FileName response Response MPAL a aCISAddParty xml! { }define FileHandler ByPass! {[2]}define XpathIndex! {[2]}define VariableIndex! .include ReusableComponents CisRetrievePersonPassthroughOneName

Look at the amount of clarity we have in the script. If the same script has to be written in a linear fashion instead of using reusable components, the script would be 28 lines instead of just 13 lines in contrast to what is shown above. Using the reusable components will reduce the rework. If we have to add one more tag named StartDate in all our scripts while declaring name variables. Add it in the component where we defined all the variables for nametags. It gets reflected in all the scripts where ever it is included.

Check that the included portion is updated when we modify the existing reusable component. Observe that in Figure 100.

Modifying the reusable component works fine as long as you do not have to add a variable, if the script is already included. What are you going to do, if you have to add a new variable in a reusable component that is already included in 100 test scripts? Addition of new variable will break the existing scripts, you will have to add the definition of the variable in all the 100 scripts. To do that, you simply add the variable in the component and to assign the default blank value in the existing scripts, define the variable with a blank value in the parent page where all these test cases are defined.

Prasad Buddha

Figure 100: Modifying the reusable component will also effect all the pages where it is included

77


Appendix – I: Syntax of All the ActionsAppendix – I: Syntax of All the Actions

Legend

All the cells in white are mandatory cells

All the cells that are in dark Grey color are optional cells

All the cells that are marked in black are conditional cells, they become mandatory when some other cell is not provided

Note: Wherever I mentioned String (or Integer or Integer/String), it can be a constant string(or integer) or a variable name included in a variable placeholder.

Prasad Buddha

Table 1: Required & Conditional Elements for Actions

Syntax of All the ActionsAction Cell Cell 2 Cell 3 Cell 4 Cell 5 Cell 6

PassThrough XPath Variable NameCount PassThrough XPath Variable NameCPassThrough XPath Variable NameCPassThrough Or Copy XPath Variable Name StringPart PassThrough XPath Variable Name Start Point End Point LengthCpart PassThrough XPath Variable Name Start Point End Point LengthCopy String Variable NameCCopy String Variable NameAdd Integer/String Integer/String Variable NameCount XPath IntegerValue XPath StringNot Value XPath StringValue IgnoreCase XPath StringContains XPath StringCValue XPath StringCValue IgnoreCase XPath StringCcontains XPath StringAll CValue IgnoreCase XPath StringAll CContains XPath StringExists XPathNot Exists XPathIs Empty XPathNot Empty XPathLength XPath IntegerIs PastDate XPathIs FutureDate XPathIs PastDate XPathIs Before XPath DateIs After XPath DateIs SameDate XPath DateIf … EndIf Variable Exists Variable NameDisplay Value XPathDisplay Count XPathException Any commentRemind Any comment# Any commentResetReset All

78


Appendix – II: Actions & Number of TagsAppendix – II: Actions & Number of Tags

Prasad Buddha

Table 2: List of Actions & Number of tags that should match to the XPath provided in cell 2 of test table

Actions & Number Of TagsAction Cell Number Of Tags

PassThrough 1Count PassThrough 0 to nCPassThrough 1CPassThrough Or Copy 1Part PassThrough 1Cpart PassThrough 1Copy N/ACCopy N/AAdd N/ACount 0 to nValue 1Not Value 1Value IgnoreCase 1Contains 1CValue 1CValue IgnoreCase 1Ccontains 1All CValue IgnoreCase 0 to nAll CContains 0 to nExists 1 to nNot Exists 0Is Empty 1Not Empty 1Length 1Is PastDate 1Is FutureDate 1Is PastDate 1Is Before 1Is After 1Is SameDate 1If … EndIf N/ADisplay Value 1Display Count 0 to nException N/ARemind N/A# N/AReset N/AReset All N/A

wcc / mdm testing with fitnesse userguide 1.0

Documents