Java - Testing code that relies extensively on an external service API -

i'm working on project ties api makes calls external service. things going enough, need start serious testing. fun part? vast majority of calls service go through single, enormous class (we'll call mastadon.class. seems fitting.) within api. there massive number of methods in mastadon making kinds of different calls , our project uses number of them. number of them public convenience methods bounce things private ones, number still quite large.

so fun of testing comes. we'd avoid making constant calls out service. testing require actions taken on other end , actions/results sent service, we'd have manually or fancy automation work on other end, we'd rather not do.

we make mock child class mastadon class, that's lot of methods stub out, , may need varying behavior depending on test , input. that's lot of muckery. use mock framework (we use jmockit things), again, that's lot of mockery of service , mocking can real pain in neck. i've considered doing bit of retooling make injectable proxy class (may not precise phrase i'm looking here, idea) acts go-between our code , mastadon class. our code never touch mastadon, instead using mastadonproxy or whatever call pass calls through. mean retooling of project , further work, might easier in long run build mastadontestproxy , stub out what's needed there, maybe injectable behavior. lot less messy mastadontest class bajillion methods refer parent mastadon method because don't need test 1 in particular.

what you? api did not seem built testing in mind. have source code whole thing, prefer not make changes if can helped. i'm leaning toward injectable proxy class, maybe there's better way of handling this, when comes end-to-end integration testing.

edit: realized proxy class may not work there number of other objects own convenience methods in api wind going through mastadon well. objecta may have dothis() method winds going through mastadon's dothis() method behind scenes. i'm thinking class extension/mock avenue may way go this...

edit: problem. mastadon inherits marginally smaller abstract class, has child class well. i'll need put facade in 3 of them, leaves me fun of sorting out how facade of these classes in way work. in addition, i'll need keep instance of each handy (or factory create them when needed) pass calls along, , there need state, perhaps changes of variables within them, etc.

i'd recommend putting in time proper testing framework using combination of 2 approaches you're considering.

(1) use fake injectable resource proxy functionality in class, and

(2) use testing extensions class/wrapping interfaces hide functionality don't need. jmock amazing -- @ least half things can come nice surprises.

while @ first might seem awful lot of work, it's best way of building flexible , extensible automated/regression testing framework. sounds are/should going for, unless intend redo same work every future project build atop "mastodon.class".

if you're going big, best put in effort. remember writing code ...: 1 mistake , have support rest of life.