Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

.NET Fest 2019. Arnon Axelrod. Test automation for developers

31 views

Published on

Traditionally developers only write unit tests (hopefully!) and QA engineers write System tests, with Selenium or some other tool. However, while this separation has some reasons, it's also a bit arbitrary and unhealthy. In this talk we'll discuss why you should be involved in all kinds of test automation and discuss best practices for utilizing the test automation to improve the development lifecycle, as well as both the internal and the external quality of your code.

Published in: Education
  • Be the first to comment

  • Be the first to like this

.NET Fest 2019. Arnon Axelrod. Test automation for developers

  1. 1. © Copyright SELA Software & Education Labs Ltd. | 14-18 Baruch Hirsch St Bnei Brak, 51202 Israel | www.selagroup.com Arnon Axelrod Test Automation for Developers
  2. 2. Arnon Axelrod Expert for: Test Automation eXtreme Programming Practices Defect-free software development ArnonAxelrod @ArnonAxelrod @ArnonAxelrod
  3. 3. Test Automation Architecture Working practices Quality & Productivity Business Structure Business Culture Documen- tation
  4. 4. Testing vs. Quality
  5. 5. Developers vs. Testers Unit Tests System Tests
  6. 6. Some common (mis?)conceptions Unit System Purpose Verify implementation Find bugs Planned, written and used by Developers Testers / Automation Developers Runs After Check-in Nightly / Before release Scope Single function or class Entire System (Like a real user) Isolation Mock all I/O (DB, Network, etc.) Full environment Data Fake Real Stability High Low Speed Very fast Very slow Failure investigation Easy Hard When written Before (TDD?) Only when dev is done
  7. 7. Another (mis?)conception… E2E Integration Unit
  8. 8. Test Scope (AKA Testbed)
  9. 9. Simplistic view on a computer system Processing InputsOutputs
  10. 10. Simplistic view on Test Automation Processing (SUT) InputsOutputs TestExpected? Pass/Fail
  11. 11. A more realistic view on computer systems…
  12. 12. End to End (System) Scope UI View Model Client Logic Server Proxy Service Layer Business Logic DAL ORM DB
  13. 13. Unit Tests scope UI View Model Client Logic Server Proxy Service Layer DAL ORM DB Business Logic
  14. 14. Client-only Test Scope UI View Model Client Logic Server Proxy Service Layer Business Logic DAL ORM DB Simulator
  15. 15. Backend-only Test Scope UI View Model Client Logic Server Proxy Service Layer Business Logic DAL ORM DB
  16. 16. Server / Service Test Scope UI View Model Client Logic Server Proxy Service Layer Business Logic DAL ORM DBFake DB
  17. 17. Under the Skin Test Scope UI View Model Client Logic Server Proxy Service Layer Business Logic DAL ORM DB
  18. 18. Functionality Test Scope UI View Model Client Logic Server Proxy Service Layer Business Logic DAL ORM DB Mock Mock Mock
  19. 19. Open Your Mind…
  20. 20. The Purpose of Test Automation
  21. 21. Find Bugs?
  22. 22. Prevent Bugs!
  23. 23. Code Structure
  24. 24. “Refactoring is all about applying small behavior-preserving steps and making a big change by stringing together a sequence of these behavior-preserving steps … As a result, when I’m refactoring, my code doesn’t spend much time in a broken state, allowing me to stop at any moment even if I haven’t finished.”
  25. 25. Simple Design
  26. 26. 4 Rules of Simple Design / Kent Beck Passes all the Tests Reveals the intention No duplication Fewest elements (functions and methods) The rules are in priority order
  27. 27. Tests should describe Observable Behavior
  28. 28. When the design is too complex...
  29. 29. Test Structure Arrange Act Assert Given When Then
  30. 30. Test Structure Experiment Steps Expected Result Claim Test name
  31. 31. Test Method Example [TestMethod] public void AddingProductWithPromotionGivesDiscount() { const decimal price = 1200; const decimal discount = 150; var iPhone = CreateProduct("iPhone", price); CreatePromotionOnProduct(iPhone, discount); var shoppingCart = CreateShoppingCart(); shoppingCart.Add(iPhone); Assert.AreEqual(price - discount, shoppingCart.Total); }
  32. 32. Best Practices for Writing Tests Keep it simple Reliability Isolate tests from one another Deterministic and Specific Expected Result Don’t assume anything about existing data Mock anything you can’t control Maintainability Readable No duplication Refactor continuously!
  33. 33. ATDD - Acceptance Test Driven Development PO defines the problem (User Story) PO & team collaborate on simplest solution Define Acceptance Criteria Implement automated test Implement Code & Refactor Exploratory testing Get customer feedback
  34. 34. Back to our (mis)conceptions… Unit System Purpose Verify implementation Find bugs Planned, written and used by Developers Testers / Automation Deelopers Runs After Check-in Nightly / Before release Scope Single function or class Entire System (Like a real user) Isolation Mock all I/O (DB, Network, etc.) Full environment Data Fake Real Stability High Low Speed Very fast Very slow Failure investigation Easy Hard When written Before (TDD?) Only when dev is done Verify Behavior  Refactoring  Clean code  Better Quality The entire team As soon and often as possible Smaller… As needed …Larger Mock anything as needed Mostly Fake data High Slower Should be made easy Preferably before (ATDD)
  35. 35. Back to the Pyramids…
  36. 36. Back to the Testing Pyramid E2E Integration Unit
  37. 37. Back to the Testing Pyramid E2E … Unit
  38. 38. Test automation is your concern! Quality comes from the code and the design Design should evolve over time. Test automation enable that Collaborate with the testers and test automation developers Most principles apply to all test scopes
  39. 39. Questions

×