Automated Testing of Web Applications

2,334 views

Published on

Testing is an important part of all software projects – and so is keeping sane. In order to not make the developers and testers lose their minds while verifying that a huge amount of features still work, the testing should be automated. What’s worse, the complexity of the underlying technologies often make it more challenging to test web applications than conventional software.

This talk will show you some tools and methodologies for automated testing of web apps and especially the user interface layer of web apps. It will discuss how to architect a web app for easy testing and what kind of tests should go where and in which situation. We’ll even have a look at how the customer requirements can be automatically tested and verified to work – exactly as specified by the ones paying the bills.

Published in: Software
0 Comments
17 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,334
On SlideShare
0
From Embeds
0
Number of Embeds
121
Actions
Shares
0
Downloads
79
Comments
0
Likes
17
Embeds 0
No embeds

No notes for slide

Automated Testing of Web Applications

  1. 1. A U T O M AT E D T E S T I N G O F W E B A P P S +Jonatan Kronqvist @zch
  2. 2. }>
  3. 3. A G E N D A • Software testing in general • Architecting for testability • Testing web UIs • What should I do?
  4. 4. A G E N D A • Software testing in general • Architecting for testability • Testing web UIs • What should I do?
  5. 5. Unit Testing
  6. 6. Integration Testing
  7. 7. System Testing
  8. 8. Regression Testing
  9. 9. End-to-End Testing
  10. 10. Acceptance Testing
  11. 11. Load Testing
  12. 12. Create VALUE for Your Customers
  13. 13. – J O H N D O E V E L O P E R “Unit testing is a waste of time, because the tests don't prove that things work correctly”
  14. 14. Red Green Refactor
  15. 15. 1. You will ALWAYS have code that worked a minute ago 2. You will have more and more automatic tests that can be run all the time 3. You will have usage examples for all of your code and API 4. All your code will be testable by default
  16. 16. Best ROI: • integration • regression • system
  17. 17. Most unit tests could be replaced by assertions
  18. 18. Focus on continuous integration and system testing
  19. 19. B E H AV I O R D R I V E N D E V E L O P M E N T
  20. 20. Scenario 1: Account has sufficient funds Given the account balance is $100 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should dispense $20 And the account balance should be $80 And the card should be returned
  21. 21. 1. Easy to define end-to-end behavior to be tested 2. Business value easily translates to this format 3. You're probably already defining user stories
  22. 22. A G E N D A • Software testing in general • Architecting for testability • Testing web UIs • What should I do?
  23. 23. • Cross browser differences • Logic that depends on the DOM • Asynchronous execution • Possibly slow execution
  24. 24. M V P Presenter Model (State) View Rendering logic Event handling logic
  25. 25. Avoid new – Dependency Injection
  26. 26. A G E N D A • Software testing in general • Architecting for testability • Testing web UIs • What should I do?
  27. 27. Unit Testing?
  28. 28. Integration Testing?
  29. 29. System Testing?
  30. 30. End-to-end Testing?
  31. 31. Web automation
  32. 32. BDD framework + Selenium or Vaadin TestBench
  33. 33. Narrative:
 As a user
 I want to perform calculations
 So that I can easily get the results without calculating in my head
 
 Scenario: Calculate 1+2
 Given I have the calculator open
 When I push 1+2
 Then the result should be 3.0
  34. 34. public class CalculatorSteps extends TestBenchTestCase {
 
 private WebDriver driver;
 private CalculatorPageObject calculator;
 
 @BeforeScenario
 public void setUpWebDriver() {
 driver = TestBench.createDriver(new FirefoxDriver());
 calculator = PageFactory.initElements(driver, CalculatorPageObject.class);
 } @AfterScenario
 public void tearDownWebDriver() {
 driver.quit();
 }
  35. 35. @Given("I have the calculator open")
 public void theCalculatorIsOpen() {
 calculator.open();
 }
 
 @When("I push $buttons")
 public void enter(String buttons) {
 calculator.enter(buttons);
 }
 
 @Then("the result should be $result")
 public void assertResult(String result) {
 assertEquals(result, calculator.getResult());
 }
 }
  36. 36. public class SimpleCalculation extends JUnitStory {
 @Override
 public Configuration configuration() {
 return new MostUsefulConfiguration()
 .useStoryLoader(new LoadFromClasspath(this.getClass()))
 .useStoryReporterBuilder(new StoryReporterBuilder() .withDefaultFormats() .withFormats(Format.CONSOLE, Format.TXT));
 }
 
 @Override
 public InjectableStepsFactory stepsFactory() {
 return new InstanceStepsFactory(configuration(), new CalculatorSteps());
 }
 }
  37. 37. }> >2500 tests <15 minutes each commit
  38. 38. Load Testing
  39. 39. A G E N D A • Software testing in general • Architecting for testability • Testing web UIs • What should I do?
  40. 40. WHAT SHOULD I DO?
  41. 41. Architect for testability and flexibility
  42. 42. Focus on Integration, End-to-end and System Tests
  43. 43. Try TDD, but don't sweat it
  44. 44. Use BDD
  45. 45. Don't forget to load test!
  46. 46. ENSURE VALUE IS CREATED FOR YOUR CUSTOMERS
  47. 47. Q & A Please rate the presentation at gwtcreate.com/agenda
  48. 48. I M A G E S U S E D • https://flic.kr/p/671Z4A • https://flic.kr/p/bsozXc • https://flic.kr/p/hRfBC • https://flic.kr/p/nQ7ac5 • https://flic.kr/p/8sf5Xt • https://flic.kr/p/4LH5Eo • https://flic.kr/p/7Lx9Kk • https://flic.kr/p/nAi4GZ • https://flic.kr/p/eguHX8 • https://flic.kr/p/4fmu9E • https://flic.kr/p/dtSHid • https://flic.kr/p/bwpVQ7 • https://flic.kr/p/fGyo6Q

×