Write tests. Not too many. Mostly integration

Re:Write tests. Not too many. Mostly integration by skybrian on Friday October 27, 2017 @02:47AM (#15566236)

This sort of discussion often gets confused because people have different ideas about what integration tests are and therefore talk past each other.

I generally avoid the term altogether and recommend testing stable API's (which are often public) and avoiding testing internal API's that are more likely to change. This assumes you have a stable API, but that's true of most libraries.

[ Parent | on HN ]

Re:Write tests. Not too many. Mostly integration by Lord_Zero on Friday October 27, 2017 @01:19PM (#15570365)

I think we are discussing what it means to test a stable API or an internal API. Not just testing them in general. We're talking about making architecture decisions on your code in the interest of test-ability. Regardless of the visibility of your API you will still need to unit test the logic will you not? Do you test your controllers and then the response from your service layer? Is all your logic in your actions?

[ Parent | on HN ]

Re:Write tests. Not too many. Mostly integration by betageek on Friday October 27, 2017 @04:37AM (#15566656)

Exactly - Integration tests !== E2E tests

[ Parent | on HN ]

Re:Write tests. Not too many. Mostly integration by profalseidol on Friday October 27, 2017 @09:09AM (#15567908)

Martin Fowler solves this by introducing:

SubcutaneousTest

https://martinfowler.com/bliki/SubcutaneousTest.html

[ Parent | on HN ]

Re:Write tests. Not too many. Mostly integration by MartinCron on Friday October 27, 2017 @09:59AM (#15568289)

Catchy.

[ Parent | on HN ]