This is, of course, very much a personal judgment, “not a religion,” but if I were asked to unit-test this (or, as the case may be, if I directed someone else to do so), I would judge this particular routine, itself, to be too trivial to unit-test on its own.   It can be visually inspected and seen to be okay ...

Except for the questionable bareword, prama.   You do have:

use strict;
use warnings;

... don’t you?

I would, instead, test each of the three application-specific subroutines that this one calls.   I would test that it can connect to the database and that the returned object isa() database handle.   This test need be performed only once, and very early in the test suite.   I would have an entirely separate, aggressive test of the other two routines.   These tests would include, for example:

• That, when given a known (and known-good) $team and $debug, it produces known-good output.
• That, when given a $team that is not good, it realizes this and raises some kind of exception.
• Ditto, if $team is undef.

I would test get_html_content in a similar way, giving it a known-appropriate but completely synthetic input hashref and checking its result through a series of regular-expression pattern tests.   Also, since we know that it might be passed an undef through code that didn’t end its loop appropriately, I would verify that the subroutine detects this possibility and that it throws an exception.

And, in passing and in closing, I would like to point out something that you have now heard me say several times:   “verify that the subroutine detects this possibility and that it throws an exception.”   In my experience, the hardest thing about debugging is not, “finding the bug.”   The hardest thing is to detect that a bug exists in an application that is not manifesting any surface symptoms (or, that is manifesting it only by incomprehensible behavior).   If a subroutine suspiciously sniffs at its own inputs and mashes the fire-alarm whenever it detects a foul smell, and if it continues to do this even in production, you will uncover the cockroaches that have been silently hiding out in the cupboard all this time (and crawling all over the “clean” ..ugh.. silverware).   If the routines aggressively test their own inputs (and if those tests, themselves, have been tested), then you can eliminate great swaths of the source-code from consideration because, “if such-and-so were happening here, then subroutine-X would have detected it, ergo, such-and-so probably is not happening here.”   This is an unspoken part of the testing rationale, as well.   It naturally yields software that is more robust and serviceable.