How to mock resolver with V2 client?

[Grendel7]

I make quite heavy use of NetDNS2 in my application, especially to get a lot more insight and control into DNS lookups. It's a great library if you want to control which nameservers to send your query, and truly disect the exact DNS response.

To test my implementation code, I make use of Mockery to mock the Resolver, as well as the Response packet, so I know my code makes the right decision based on the information returned by the DNS query.

This worked fine with the V1 client. But this approach doesn't work at all with the V2 client, because:

• Mockery works by dynamically extending the parent class with a mock class, so it can intercept calls while still passing type checks. But with the V2 client, almost every class is designated as final, which prevents this trick from working.
• An alternative to this would be to build a mock based on an abstract or an interface, but the client contains no abstract classes or interfaces.
• Mockery supports proxy objects, but this breaks all type checks. And I need input types for the dependency injection to work correctly.
• Many data representation objects take only data as their input argument, with no definition as to what this data is supposed to look like, making it hard to construct these data objects manually for testing.

Based on this, my questions are:

• What is the recommended way to test code that uses this library? Was this use case even considered? And no, just testing against actual DNS servers is not feasible for me.
• Would you be willing to add interfaces to the library, at least for any class that's final?
• Or would you be open to dropping the final designation from most classes at all?

For these last two, I'd be willing to put in the work, but I would like to know beforehand what you'd be willing to accept.

[mikepultz]

hey @Grendel7,

I've never used Mockery before, but I think I get the idea, and I understand why it wouldn't work with this library as-is.

Obviously, the best way to test the code is against a real DNS server; in my PHPunit files, I have several cases where I reach out to both public DNS resolvers, and a public DNS server that I control for testing- this is ideal since I know exactly what's configured in my DNS server.

If that doesn't work in your case- I've also created PHPunit tests for the parser itself; e.g the ParserTest::testParser() function; this takes a "display" formatted DNS entry, e.g.:

example.com. 300 IN CAA 0 issue "ca.example.net; policy=ev"

converts it to wire-format (binary), then passes the binary back into the library (just like a response back from the DNS server), which parses it back down to the DNS entry string, and I compare the result against the original to ensure they match.

This isn't 100% obviously, as it doesn't take into account the server actually parsing my request, and encoding it's own response- but the only way to get that is to interact with the DNS server itself. This test does confirm that each RR type encodes / decodes properly within the library itself.

I would suggest taking a look at the PHPunit tests I've already created, and see if any of that gives you what you need; I'm also happy to extend these unit tests to cover more- they're by no-means complete. If you want to extend them yourself, or give me more details on what you're looking to test, and see if we can make them work with the current codebase.

I don't love the idea of dropping the final keyword; it is a library, and it's intended to be used that way, vs being extended into some codebase with unknown consequences.

Adding interfaces might be ok, but there's probably ~100 separate classes in the library, and most are marked as final- so I guess it depends on what you need? Does Mockery just need an entry point? e.g. just the Resolver class?

Mike