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.

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. Arnon Axelrod
Expert for:
Test Automation
eXtreme Programming
Practices
Defect-free software
development
ArnonAxelrod
@ArnonAxelrod
@ArnonAxelrod

3. Test
Automation
Architecture
Working
practices
Quality &
Productivity
Business
Structure
Business
Culture
Documen-
tation

4. Testing vs. Quality

5. Developers vs. Testers
Unit Tests System Tests

7. 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

8. Another (mis?)conception…
E2E
Integration
Unit

9. Test Scope (AKA Testbed)

10. Simplistic view on a computer system
Processing
InputsOutputs

11. Simplistic view on Test Automation
Processing
(SUT)
InputsOutputs
TestExpected?
Pass/Fail

12. A more realistic view on computer systems…

13. End to End (System) Scope
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB

14. Unit Tests scope
UI
View Model
Client Logic
Server Proxy
Service Layer
DAL
ORM
DB
Business Logic

15. Client-only Test Scope
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
Simulator

16. Backend-only Test Scope
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB

17. Server / Service Test Scope
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DBFake DB

18. Under the Skin Test Scope
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB

19. Functionality Test Scope
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
Mock
Mock
Mock

20. Open Your Mind…

21. The Purpose of
Test Automation

22. Find Bugs?

23. Prevent Bugs!

24. Code Structure

25. “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.”

26. Simple Design

27. 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

29. Tests should describe Observable Behavior

30. When the design is too complex...

31. Test Structure
Arrange Act Assert
Given When Then

32. Test Structure
Experiment
Steps Expected Result
Claim
Test name

33. 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);
}

34. 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!

35. 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

36. 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)

37. Back to the Pyramids…

38. Back to the Testing Pyramid
E2E
Integration
Unit

39. Back to the Testing Pyramid
E2E
…
Unit

40. 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

41. Questions