Automation patterns on practice


Published on

Как надо правильно строить автоматизацию тестирования с нуля, что нужно применять, а то не нужно применять при проектировании архитектуры. Какие виды фреймворков бывают, что с ними надо делать. Все и много другое вы сможете найти в этой презентации

1 Comment
  • why it doesn't downloadable? Is this a secret information?
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Automation patterns on practice

  1. 1. Presented by: MykolaKolisnyk<br />1<br />Automation Patterns on Practice. Automation Architecture creation.<br />
  2. 2. What’s it all about?<br /><ul><li>Framework structure
  3. 3. Framework types
  4. 4. Design patterns
  5. 5. Behavioral patterns in automation</li></li></ul><li>Framework is the core<br />06.02.11<br />Libraries<br />Tests<br />Engine<br />Configs<br />Reporting<br />Resources<br />Core components<br />
  6. 6. Framework types<br />06.02.11<br />Functional decomposition<br />Object-based<br />Data-driven<br />Keyword-driven<br />Behavior-driven<br />Model-based<br />Hybrid<br />
  7. 7. Functional Decomposition<br />
  8. 8. «Data-Driven» Approach<br />
  9. 9. Object-based Framework<br />TestSetClass<br /><ul><li>Tests
  10. 10. Run()</li></ul>List of<br />TestClass<br /><ul><li>Actions
  11. 11. Run()</li></ul>List of<br />ActionClass<br /><ul><li>Run()</li></ul>for each Test in this.Tests<br />for each Action in Test.Actions<br />Action.Run()<br />
  12. 12. «Keyword-Driven» Approach<br />
  13. 13. Behavior-driven<br />Text instruction<br />WhenI log into the system as “login”/”password”<br />Actual Code<br />When/log into the system as “(.*)”/”(.*)”/do|login,password|<br />app.login( login , password )‏<br />end<br />class App<br />def login( username , password )‏<br /># Some actions<br />end<br />end<br />
  14. 14. Model-based framefork<br />Action 0-1<br />Action 0-1<br />Initial state<br />Action 5-1<br />State 1<br />State 5<br />Action 1-1<br />Action 2-2<br />Action 2-1<br />State 2<br />State 4<br />Action 0-1<br />State 3<br />Action 3-1<br />Final State<br />
  15. 15. Patterns<br />06.02.11<br />
  16. 16. What does pattern mean?<br />06.02.11<br />Pattern is a typical <br />solution for typical task<br />
  17. 17. Global Objects<br />06.02.11<br /><ul><li>Should be only one in the system
  18. 18. Should be initialized only once
  19. 19. Should not be modified from outside</li></ul>Engine driver<br />Config<br />
  20. 20. Singleton<br />06.02.11<br />Local instance<br />Private constructor<br />All operations are done via local instance<br />
  21. 21. Immutable & Lazy initialization<br />06.02.11<br />Filled only during initialization<br />Initialized at first method call<br />
  22. 22. Engine-specific patterns<br />06.02.11<br /><ul><li>Each unit implementation should be abstracted from interface
  23. 23. Units should represent actual command to execute</li></ul>Engine driver<br />NOTE: applicable for Object-based, Keyword-Driven, <br />Behavior-driven, Model-based approaches<br />
  24. 24. Command & Interface & Delegate<br />06.02.11<br />Common interface for each class (Interface)<br />Object represents the action (Command)<br />ActionClassA<br /><ul><li>Run()</li></ul>TestClass<br /><ul><li>Actions
  25. 25. Run()</li></ul>List of<br />ActionClass<br /><ul><li>Run()</li></ul>ActionClassB<br /><ul><li>Run()</li></ul>ActionClassC<br /><ul><li>Run()</li></ul>Actual execution is delegated to aligned class objects (Delegate)<br />
  26. 26. Functional design<br />06.02.11<br />Independent functions<br />
  27. 27. Resource-specific patterns<br />06.02.11<br /><ul><li>Resource should represent logical structure rather than physical
  28. 28. If engine driver is used it should be used implicitly</li></ul>Resources<br />
  29. 29. Page object<br />06.02.11<br />Objects functionality is extended via external class (Decorator/Wrapper)<br />
  30. 30. Page Factory<br />06.02.11<br />Implicit page object initialization<br />Usage example:<br />
  31. 31. Anti-Patterns<br />06.02.11<br />
  32. 32. Big ball of mud<br />06.02.11<br />
  33. 33. God object<br />06.02.11<br />Too much methods in one class<br />
  34. 34. Hard & Soft Coding<br />06.02.11<br />Magic numbers<br />Configuration hell<br />
  35. 35. Dependency hell<br />06.02.11<br />Test 8<br />Test 1<br />Test 7<br />Test 9<br />Test 2<br />Test 6<br />Test 3<br />Test 5<br />Test 4<br />
  36. 36. Summary<br />“Framework”, “pattern”, “architecture” are not magic spells<br />Framework identifies how we structure overall solution<br />Each framework type uses specific set of patterns<br />Pattern is the solution for specific task <br />Good solution is the balance between complexity and simplicity<br />06.02.11<br />
  37. 37. 06.02.11<br />Узнай больше на <br />