Angular Ruhr @ Comline GmbH

Transcript

1. AngularRuhr @ New Host Comline GmbH
2. Agenda Talk 1: Bessere Architekturen mit modernem Angular und Nx Speaker: Dominik Pieper - Topic Lead Frontend, Conciso GmbH Talk 2: Testing all the things - e2e testing patterns Speaker: Tobias Brenner - Principal Expert Application Development
3. Dominik Pieper Topic Lead Frontend / Solution Architect +49 160 99527824 dominik.pieper@conciso.de https://conciso.de Bessere Architekturen mit modernem Angular und Nx
5. Organisation in modules
7. Standalone Components: • Components & modules in one • every component knows its dependencies
8. 8 Standalone Components: Mental Model
10. 10 Components – Structure with folders …
11. 11 and barrels. Components – Structure with folders …
12. 12 From clear structure …
13. 13 … to this.
18. First takeaway: Nx brings back structure into your code.
26. All “booking” connections
27. 27 Unified tooling
28. 28 Unified & smart tooling
29. 29 Better CI tooling
30. 30 Testing just the affected …
31. 31 … on automated basis.
32. Second takeaway: Nx is safer & easier than any other.
33. Wide compatibility …
34. … with some of special interest for me J
35. Third takeaway: Nx is adjustable to your special needs.
36. More structure. Safer & easier. Adjustable.
37. Thank you
39. Testing all the things - e2e testing patterns Tobias Brenner E-Mail: tobias.brenner@eon.com Handy: +49 175 4751 883 E.ON Digital Technology GmbH
40. What is the problem? • Scaling the test codebase > Scaling ordinary code • Test code prone to refactoring • Selector bleeding • Slow test executions • Flaky tests • Setup test code vs. Actual test code • Too complex test code • It‘s too much work to write tests • Are you testing too much? <ul> </ul>
41. Green field work is easy
42. … How to prevent it from becoming that?
43. Design-Patterns to the rescue
45. Let it scale!
46. Easy stuff first - Selectors • Don‘t use complex dom selectors • Don‘t bind it to your components dom structure • Instead: • Use test-id attributes • Use Naming conventions for them • Don‘t expose them • … later more about that
47. How to write test code which ages well • Strict encapsulation • Create action files for each component • Write utility fns for state checks (expections) • Write utility fns for interaction (state change) • Keep the test code DRY • Use fns composition • Delegate work to other, existing action files • Create action file for each view • Create scenario files • Static test data • Mock HTTP Layer (Disclaimer)
49. Naming things properly helps Atomic Action Flow Scenario
50. FAQ • Do I need a specific testing library? • Mocking the HTTP in e2e tests, really? • Isn’t this too much effort?
51. Now it is time for code
52. How to write test code which ages well - recap Congrats: you‘ve created you own testing DSL Create action file per component Create action file per view Compose atomic actions to flows Create scenarios out of flows Use static test data
54. Tobias Brenner E-Mail: tobias.brenner@eon.com Handy: +49 175 4751 883 E.ON Digital Technology GmbH
55. Feedback Bitte bewertet uns auf Meetup.com