Hi. On Sun, Jan 10, 2010 at 10:43 PM, Dana Hudes <dhu...@hudes.org> wrote:
> If you call it Test::DNSserver ? > Not ::server bec that would imply you are a server when you are a client. > Calling it Test::DNSServer is like saying that Test::File should be called Test::FS, IMHO. I'm not checking whether a DNS server is okay, I'm checking the zone attributes, like Test::File checks file attributes. > In any case, the Check::DNS name does sound more appropriate. IDK about > Check::Net::DNS. That implies it's Net::DNS you are checking > Perhaps Check::Server::DNS?? > I'm not checking a server, I'm testing DNS records. Moreover, as I point out previously, I'm using Test::Builder to provide TAP. This, quite honestly, seems to me like a good candidate for Test:: namespace. I appreciate the comments and suggestions (and do I consider them) but honestly, I just wanted some thoughts on Test::DNS vs. Test::DNS::Resolver (and the sorts). I've already settled in my mind that it's a /^Test::DNS.*/ > I do see a use for TAP. I like the idea of saying > ok(soa,"cpan.org") > and even > ok(ns, "cpan.org" eq [ list of name servers ] ) > It's object oriented out of comfort. A functional interface shouldn't be tricky, but in order to maintain the nameservers (and other persistent features for DNS and testing behavior), I prefer to use OO instead of multiple global variables. > It is more than object oriented. You use OO to extend TAP I guess but its > really logic programming, a rules system > I would think we could add this to Nagios or BigBrother. > Quite possibly. We had a system at $work that took us a while to write, it was over 200 lines. Using Test::DNS, we rewrote the whole thing in about 20 lines, clean and beautiful, in roughly 10 minutes, including all the nasty edge-cases. Sawyer.
