Difference between revisions of "TDD and APIs Theory vs Practice"

From CitconWiki
Jump to: navigation, search
(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...")
 
m
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
How are we testing contracts/services?
+
'''How are we testing contracts/services?'''
Practical TDD Unit and Service tests
+
 
 +
'''Practical TDD Unit and Service tests'''
  
 
Question may become who writes the mock?
 
Question may become who writes the mock?
 +
 
Quality and process needs to be driven by business and through collective agreement
 
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 production after limited tests pass
Line 8: Line 10:
 
   Sometimes it may be builds includes all dependencies to force the people discussion to resolve conflicts
 
   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
 
   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
 
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
 
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
 
Pre-prod environments ROI vs Cycle Time vs Time to Market
 +
 
Know critical macro services
 
Know critical macro services
 +
 
Version and correct granularization helps
 
Version and correct granularization helps
 +
 
Tools like Apiary and Swagger may help with a re-usable blueprint
 
Tools like Apiary and Swagger may help with a re-usable blueprint
 +
 
Technologies that attract developers include:
 
Technologies that attract developers include:
 
   Angular/REACT  
 
   Angular/REACT  
 
   Node.js
 
   Node.js
 +
 
Dan North software talk: http://www.infoq.com/presentations/microservices-replaceability-consistency
 
Dan North software talk: http://www.infoq.com/presentations/microservices-replaceability-consistency
 +
 
Containers make it easier to test and stage
 
Containers make it easier to test and stage
 +
 
With TDD don't trust low or very high coverage
 
With TDD don't trust low or very high coverage
 +
 
Coverage with TDD needs to be practical
 
Coverage with TDD needs to be practical
 +
 
Understanding severity of defects is critical
 
Understanding severity of defects is critical

Latest revision as of 10:26, 4 October 2015

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