Call Girls Manjri Call Me 7737669865 Budget Friendly No Advance Booking
Break through e2e-testing
1. The Odds of End to End
Testing
Sunil Kalangi
Arun Subramanian
Tameem Ahmed
tamahmed@paypal.com
2. Overview
• The Problem
• The Solution
• Break it Out of Monotonous, Flaky, Time Consuming approach
• TestNG Listeners
• Master Suites and Sub suites
• Workspace Area
• How To’s
• Demo
• Odds & Ends
• Advantages
• Continuous Integration
• Concept – Unique Rows
3. The Problem
End to End Automation Test Cases was always and is one big
block touching various components/layer in one single block.
What if Component n-1 fails ?
Start from start ? Doesn’t make sense ….
What if you want to test just component 3 ?
Not possible in an environment where you have 20
components.
4. The Problem cont.…
What if the team testing component n-1 wants to do some
valuable testing meaning generating the data required prior to
hitting component n-1 ?
Not Possible as it is additional learning, implementation and
maintenance of scripts.
What if some other component is introduced before component
n-1 is introduced ?
Requires you to change the whole structure of the test cases modify
inputs and outputs etc.,
5. The Solution
Break it up…..
Let them live independently on their own for component testing.
Design the logic to tie them together for an end to end experience.
Now you have the ability to connect any component output to any
component.
Ability to test independently.
7. Concepts
TestNG listeners: Listeners are events which are triggered with
a test context. These are the classes you write, which
implement some interfaces that TestNG provides, so that when
TestNG Raises certain events it will look for all “classes” which
are basically looking for such events and call the respective
event handler’s in them. Link here on TestNG Listeners.
We don’t have to write the listeners again and again, write once
for one layer and you would have the same format just that
what information you record will differ.
8. Concepts
Worspace: Temporary store for a build job, has all of the results/
source code / build files, etc., which is basically refreshed for
every build you kick off.
11. How To’s
Listener Code Implementation:
package test.tmp;
public class TmpSuiteListener implements ISuiteListener {
@Override
public void onFinish(ISuite suite) {
System.out.println("Finishing");
}
@Override
public void onStart(ISuite suite) {
System.out.println("Starting");
}
}
12. How To’s
Record the data in an excel sheet using listener code
on a successful run, use data provider and connect it
to the other component, read the data and use it.
14. Odds & Ends
This approach will be fruitful for an environment
which has multiple layers/teams.
15. Advantages
• Now the entire test case logic is component based.
• Manageable
• Readable
• Robust
• Independent
• Reliable even in cases when some components are not working or being worked on.
• You can do whole lot with the data produced, share with PD other teams and save time.
16. Continuous Integration
Data Capture is a challenge when it comes to continuous integration as the build
jobs clear the workspace every build you kick off. The whole theme for us is to
preserve the data and move forward with layer below.
Things to do in order to preserve data in continuous integration environments
Jenkins etc.,
Archive the artifacts *.xls
17. Unique Rows
Using the layered approach described above, we can benefit in time at the lower level layers.
How ?
When capturing the data for a layer mark it as a unique entry in the excel file itself and when you use data
provider to load the data pick it up in a hash map which will give you unique set of rows on which the lower
level layers can run tests.
Example:
Validations doesn’t really need to happen on all of the test cases but the validations have to be thorough.
Lets say you do 100 different test runs on Component 2 with all possible commination's. You will mark like 10 –
15 of them as unique rows in the results file and when Component 3 has to run the test it will load 15 of the
unique rows and start running the tests on these 15 rows only. Real time benefit : 80% of time saved.