TDD and APIs Theory vs Practice

From CitconWiki
Revision as of 10:03, 3 October 2015 by Nick Edmonds (talk | contribs) (Created page with "How are we testing contracts/services? Practical TDD Unit and Service tests Question may become who writes the mock? Quality and process needs to be driven by business and th...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

How are we testing contracts/services? Practical TDD Unit and Service tests

Question may become who writes the mock? Quality and process needs to be driven by business and through collective agreement

  Sometimes it may be developer who pushes to production after limited tests pass
  Sometimes it may be developer who pushes to pre-prod for further tests
  Sometimes it may be builds includes all dependencies to force the people discussion to resolve conflicts
  In all cases there are benefits of face to face discussion where needed

Tests can be a different language if the services are consistently built Pub/Sub model can make it easier to understand but fully adopting Pub/Sub has it's own complexities Pre-prod environments ROI vs Cycle Time vs Time to Market Know critical macro services Version and correct granularization helps Tools like Apiary and Swagger may help with a re-usable blueprint Technologies that attract developers include:

  Angular/REACT 
  Node.js

Dan North software talk: http://www.infoq.com/presentations/microservices-replaceability-consistency Containers make it easier to test and stage With TDD don't trust low or very high coverage Coverage with TDD needs to be practical Understanding severity of defects is critical