Granularity of the Test Definition feature file

[bigludo7]

@sachinvodafone @akoshunyadi We have a discussion in Commonalities about Test Definition file granularity (camaraproject/Commonalities#117 (comment))
I tend to think that for our projet probably 3 distinct files make sense (one for roaming, one for connectivity, one for subscriptions) as this is 3 distinct feature. Looking for your feedback here or in the commonalities issue. Thanks

[akoshunyadi]

Alternatively, to keep it simple, we could create only 1 feature file for all cases, since all operations do query the device status in different scenarios. I think, generally, if the endpoints are not so strongly related, then the API should be cut into multiple yaml's and then again you can create 1 feature file / API. Which I think should be the case for QoD. But here I would be fine with 1 feature file, and that's it.

[bigludo7]

@akoshunyadi Regarding device status the operations could be perceived as 'business' close but from a technical perspective there are away. From my perspective, both from the server but also for the API consumer, the POST /roaming & POST /connectivity in one hand and all operations related to subscriptions in a second hand are different as they require distinct IT assets. We can fairly assume that some company will be able to implement first the synchronous endpoints (roaming and connectivity) and later the subscriptions that why I was thinking that having 2 files could be an option.... but not a blocking point for me as long as we have a consensus