Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

How To Practice TDD Without Shooting Yourself In The Foot

196 Aufrufe

Veröffentlicht am

It's 2018, so practices like Test Driven Development (TDD) have long found their way into organizations. However, the practices and principles to keep those unit tests maintainable haven't really changed. Still, I regularly talk to developers that somehow ended up with an incomprehensible unmaintainable set of unit tests that they once believed in, but are now holding them back. So in this session I like to provide a refresh of those fundamental ideas and talk about why you should practice TDD, revealing intentions, naming conventions, state versus interaction based testing, and how to stay out of the debugger hell with proper mocking and assertion frameworks.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

How To Practice TDD Without Shooting Yourself In The Foot

  1. 1. Dennis Doomen | @ddoomen | Aviva Solutions | The Continuous Improver
  2. 2. An opinionated definition
  3. 3. (in my definition)
  4. 4. • Write a great unit test • Generate stubs using R#, Rider, etc • Ensure test fails for the right reason • Implement the real deal • Ensure test succeeds • Identify alternative scenarios • Repeat twice • Refactor.
  5. 5. Order Processing IStoreOrders<T> + CreateQuery<T>(); + Add<T>(); + Delete<T>(); NHibernate Repository Order Processing IStoreOrders + GetIncompletedOrders(minValue); + StoreOrder(); + CompleteOrder(); OrderRepository VS
  6. 6. Command Handlers Commands Domain Model Event Store Events App Query Store RavenDB Projectors Events API Controller Projections Events
  7. 7. • Define the boundary carefully • Use BDD or AAA when applicable • Don’t repeat the context in names • Don’t use technical names • Avoid constants • Use Test Data Builders for the irrelevant parts • Show relevant dependencies • Only assert the relevant parts • Keep refactoring • Keep out of the debugger hell.
  8. 8. • Example code https://github.com/dennisdoomen/EffectiveTddDemo • Chill https://github.com/ChillBdd/Chill • Fluent Assertions https://www.fluentassertions.com • Laws of Jeremy D. Miller http://codebetter.com/jeremymiller/2005/10/21/haac ked-on-tdd-and-jeremys-first-rule-of-tdd/ • Xunit Patterns http://xunitpatterns.com/ • Liquid Projections https://github.com/dennisdoomen/LiquidProjections • Test data builders http://www.natpryce.com/articles/000714.html