regismarteau
commented
1 month ago Hello Edouard and thank you for your question! You're completely right, it is true that going through Http request add some delay on the feedback loop (not that much in fact).
I've already tried during my previous experience to test the behaviour directly through commands and queries, but I've often noticed that some issues occured due to the lack of API testing. Additionally, you're taking distance with your prod environment and getting closer to the implementation which could result with unexpected behaviours that you definitively don't want to get.
Also in that case, it is imperative for me to develop (and to maintain!) a separate integration tests stack that might overlap acceptance tests, and cannot be as exhaustive. It can impact your feedback loop in some way and your global development efficiency (which is the whole point).
As I consider reliability and consistency over speed, as I noticed that the execution time gap isn't that big, and as I tried both approaches in a professional context, I personally prefer this one. :)
Finally, I would say that when acceptance tests stack becomes too big, there are solution to split them, by feature's family within separate projects for example. Or maybe it's time to consider to split your BC. :D
Hope this answer is clear enough! :D
Hi Regis,
I see that your acceptance tests dispatch a Http request.
I can imagine the benefits to test that the controller is covered, but does that not imply some overhead to run each test through a HTTP request, which implies several operations such as (de)serializing items ?
Of course, in the context of this project, there won't be any noticeable difference. But do you think that there is a project size where this overhead can lead to a longer feedback loop ?