Without a UI, I know Acceptance Test Driven Development can still be performed against APIs etc (sort of headless vertical slice development and testing if you will) but where do we draw the line for the boundaries of things we are testing (I know, I know...it depends!)
Should we employ End-To-End testing or Component style testing? Or both ( and if the latter how do we deal with stuff coming out of test doubles)
Given a REST API, which creates commands, to be consumed asynchronously, and a messaging endpoint performing some action based on a command, which all reside in the same Microservice. To my mind, the boundaries are at the input into the REST api and the output of the messaging endpoint.
From a Microservice perspective, I can push in a request and get a message out of the back (mocking interactions with nearest neighbours) to get me to an end state in an End to End style test, and have done so. The drawback with this though is we start to create an hour glass instead of a testing triangle, If I am to ATDD all features like this. Which is a fair criticism
A bit of a debate has arisen about not exercising expensive HTTP calls, and messaging or Databases (which is all fair enough), more an End to End style of testing (favoured in GOOS for example) but rather using Component style testing but then this would omit the messaging aspect unless a test double for the messaging was pretty clever.)
Has anyone got any experience of any approach(es) to take, or considerations.