Difference between revisions of "TDD and APIs Theory vs Practice"
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...") |
Nick Edmonds (talk | contribs) m |
||
| 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 9: | ||
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 | ||
Revision as of 09:25, 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
