Let's say i've written a perl program with classes and methods and subroutines and all that. I have a test program which tests all the class methods and the subroutines, but what about the "glue code" in between it all in the main program?

You need to test, not only the object in isolation, but also its interface to its client, as used by what you refer to here as “glue code.”   Tests are built-up in a sequence, from the atomic to the contextual.

Consider, as an excellent example, the testing strategy used by the venerable DBI, or any similar very complex CPAN module.   The first tests that are run exhaustively test low-level attributes and behaviors of the object(s), including unpublished ones that you do not directly use or see.   Subsequent tests rely upon the fact that all of those more-atomic tests succeeded.   (Such that they might BAIL_OUT if not, as there is truly no point to continue.)

The final tests in the overall test-sequence set up actual scenarios in which multiple calls are made to the object, as a client might do when that client is doing either the right-thing or the wrong-thing.   They are mimicking the “glue code.” The client should find that sequences of calls which are supposed to be made in-sequence produce the intended result, and that sequences which are not valid are, in fact, detected and rejected in the proper way.   If the contract that the object makes with its users are that certain combinations of events are invalid, then the object must enforce that contract, and so you must by testing prove that it [still] does.  

It is frequently suggested that you should “write the tests first,” and use those tests to specify (and then, to demonstrate) what the object is supposed to do.   Now, go write the code that passes 100% of those tests, first to last, top to bottom, stem to stern.   I have tried that approach, and found that it worked.   That it yielded trustworthy code ... and that it compelled me to think the thing all the way through before I started writing.   We all know the old saw that says, “the last 20% of the code takes the other 80% of the time.”   Well, I’ve found that this technique significantly reduces that effect.   Development proceeds, at first blush, “more slowly,” yet it proceeds much more surely.