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.

Automation patterns on practice


Published on

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

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