Vet inte om detta kommer att vara allas svar, men efter lite grävande, här är vad vi kom fram till.
Felet beror uppenbarligen på att lyssnaren inte accepterade anslutningar, men varför skulle vi få det felet när andra tester kunde ansluta bra (vi kunde också ansluta utan problem via sqlplus)? Nyckeln till problemet var inte att vi inte kunde ansluta, utan att det var intermittent
Efter lite undersökningar fann vi att det skapades en del statisk data under klassinstallationen som skulle hålla öppna anslutningar under testklassens liv och skapa nya allt eftersom. Nu, även om alla resurser släpptes korrekt när den här klassen gick utanför räckvidden (via ett finally{}-block, naturligtvis), fanns det några fall under körningen när den här klassen skulle svälja alla tillgängliga anslutningar (okej, dåligt praxisvarning - detta var enhetstestkod som kopplades direkt istället för att använda en pool, så samma problem kunde inte inträffa i produktionen).
Korrigeringen var att inte göra den klassen statisk och köras i klassinställningarna, utan istället använda den i metoderna per metod setUp och tearDown.
Så om du får det här felet i dina egna appar, slå en profilerare på den där dåliga pojken och se om du kan ha en anslutningsläcka. Hoppas det hjälper.