When using a selector layer pattern, what does the community think is the best practice around testing? I kind of hate writing a test for no reason other than to test a query, and if your integration tests are being done, you will get coverage from them.
But if you need to deploy an updated selector class quickly, you must run all the associated integration tests to get it into prod. What does everyone think the correct method is here?
My selector classes (fflib - and I have a lot of them), all have a corresponding testmethod.
Classes should have unit tests, period.
Classes with unit tests can be deployed efficiently without having to run all tests
Selector class methods actually have logic - they take in arguments like ContactsSelector.newInstance().selectByEmail(Set<String> emails) so you need to mock real Contacts with different emails and verify that only the matching Contacts by email are fetched
Yes, it is tedious but I sleep better at night knowing I didn't take shortcuts
It is worth mentioning that selector classes have two huge advantages
Reusability across the code base
They can be mocked in unit tests - thus saving the need to do DML setup. Mocking is also the only solution when the underlying objects can't be setup with DML (like AsyncApexJob)
Hence, given these advantages, writing unit tests is even more worthwhile
I don't think there's any difference in best practice here (compared to best practice in testing anything else).
That is to say, your goal here is still to execute code (to gain coverage for it) and to assert that the results from executing that code match your expectations. The results you have here are:
The number of records returned
The fields and related (child or parent) data that is included
That first item is perhaps not so useful, but the second item is. That's a good enough basis for a dedicated unit test in my books. getPopulatedFieldsAsMap() and .getSObject() would be helpful for making assertions against returned fields.