Ok, I think I definitely mixed up some terms here. I am not that interested in “unit testing” this code. Based on further research https://metacpan.org/pod/Test::BDD::Infrastructure::Socket seems to do what I want. And I guess this means that I should take a “Behavior Driven Design” BDD approach and use that module for “Test Driven Infrastructure” TDI which is, in this case, more correctly called TDD since I am not actually creating new “infrastructure” just some socket code running in an application.
I can see where unit testing would be interesting if I was doing something complicated after the connection is made. In that case the logic going on could be tested without the additional complication of the actual socket. I suppose the mocked socket could be passed as what people like to call a “dependency injection”? Not sure why the extra terminology is needed for passing something as a parameter though. Yes, it does seem that separate Unit and Integration testing is the winning meta-pattern! I did not explicitly use BDD here. I can see how if I had more of a background in this I would have started from scratch with defining the behavior (BDD) with Cucumber and then writing code to ensure all the Cucumber tests pass (TDD). Maybe the only frustrating part of this, terminology aside, that the amount of test code is likely to far exceed the amount of code being tested! From: Bill Ricker <[email protected]> Sent: Tuesday, August 23, 2022 1:29 AM To: Adam Russell <[email protected]> Cc: [email protected] Subject: Re: [Boston.pm] unit testing socket code On Mon, Aug 22, 2022 at 10:31 PM Adam Russell via Boston-pm <[email protected]<mailto:[email protected]>> wrote: I have some networking code in Perl. Fairly low level in that I use raw sockets, accept(), etc instead of the higher level IO::Socket package. I'd like to test this code but am not sure what the best approach is. There doesn't seem to be a convenient testing framework like there is with WWW testing. I guess I could use Expect and throw something together but that seems a bit clunky. What I'd like to do is test client(s) connect to port XYZ, sending messages, and testing the output returned. Sounds simple enough but it isn't clear how to proceed in anything other than a kind of ad hoc way with Expect or whatever. Any advice? You said "unit testing" which to me would mean you wanted to mock the socket accept(), so it's only testing the logic of the unit under test per se, but then say you want to have an actual socket to port XYZ with stuff coming back. Mocking Perl built-ins is awkward but possible, and possibly less awkward . (The Testing community AFAIK has failed to provide a catchy name for a single-layer interface test that does tests both a unit under test and the one layer below the interface it calls, verifying that the two layers agree on the definition of the interface, which is unfortunate. If someone knows different, i'd appreciate having the name!) Is your testing goal to actually see bits move over a tame, pet socket, or to provide TDD or regression testing Unit tests for the logic that uses the socket ? If both, separating them into Unit and Integration tests is a winning meta-pattern. _______________________________________________ Boston-pm mailing list [email protected] https://mail.pm.org/mailman/listinfo/boston-pm
