Create a stub of 3rd party Java library

Question

My task is to create stubs for a 3rd party Java library that our application will make calls to. My problem is how to define the class of the method "return type" (if that's the correct Java terminology). I don't have access to the full documentation of the 3rd party API, just a list of methods. For now, my stubs just need to return true/false or 1/0, whatever

Here's an example of one method to illustrate. This is what I have been given

OobResponse RequestOobRequest(
   String ClientName,
   String SecurityLink,
   short LenofHHU,
   RequestMode RequestMode)

I have no idea what OobResponse or RequestMode are supposed to be, but I should still be able to create stubs, right?

So far, this is all I have.

public class stubber {

  public class OobResponse {
    public int someVar;
  }
  public class RequestMode {
    public int someVar;
  }

  public OobResponse RequestOobRequest(
    String ClientName,
    String SecurityLink,
    short LenofHHU,
    RequestMode RequestMode)
  {
      OobResponse oobr = new OobResponse();
      return oobr;
  } 
}

Answer 1

One possibility (academically at least) is to use a facade to the actual 3rd party library. You could probably create a class which has the methods that you need and your main code calls this class in place of the the 3rd party library, include all the methods that you need and return 1/0 etc., when the library is available dispatch the calls to the library from the facade.

However, there is a fair bit of caution, if the actual data model of the library is complex you could end up replicating all of them or their equivalent in your code, if it is not (like simple strings etc.) then this approach would work.

With reference to the comment below for en example, i am adding the following:

Let us say we have a class:

public class Class0{

 public String method0(String arg0){return "from Method 0";}
 public String method1(String arg0, String arg1){return "from Method 1";}

}//class closing

Now let us say we only have the signature for the above class and not the class itself, then we can do the following (for now):

public Class0Facade{

 public String method0(String arg0){return "from Method 0";}
 public String method1(String arg0, String arg1){return "from Method 1";}

}//class closing

Rest of your code can use the 'class0Facade' class and go ahead.

When the actual Class0 is available, you would change Class0Facade, in the following way:

public Class0Facade{

 protected Class0 deligate;

 public Class0Facade(){delegate=new Class0();}
 public String method0(String arg0){return delegate.method0(arg0);}
 public String method1(String arg0, String arg1){return delegate.method(arg0, arg1);}

}//class closing

Rest ot four code does not need to change

Answer 2

The documentation you have is weird, since variable and method names do not hold Java convention of using camelCase. Also, what you seem to be ordered to do would hold minimal later use. However, the way I understand your problem you could do:

• create new package for all classes you will be stubbing. That will be relevant later
• actually stub stuff. That is, for every class in the documentation that is not built into java create the class. I assumed that what you wrote is a method declaration (made most sense to me, though it could also be a constructor or whatever), it needs to be a part of some class, I called it "Unknown" below. Replace that name with actual class name.

For your example you would need:

public class RequestMode {

}

public class OobResponse {

}

public class Unknown {

    public OobResponse RequestOobRequest(
            String ClientName,
            String SecurityLink,
            short LenofHHU,
            RequestMode RequestMode){
        return new OobResponse(); // or null, whatever since it is a stub
    }
}

Note, that when stubbing you do not create any additional variables (like someVar you tried to add), ONLY what API allows you to access (only classes and public methods within would be a good rule of a thumb). You could also use interfaces instead of classes, it would be cleaner, but there are legitimate reasons not to (when you want a code with new StubbedClass() to compile for example).

Now, in your actual code you (or someone) will be able to use your stubs like the actual library:

public class YourBusinessClass{

     public OobResponse getOobByClientName(String clientName){
         return new Unknown().RequestOobRequest(clientName,...);
     }

}

• When you get the actual library you can replace imports from stub package in your actual code that uses it to the actual library package.

That is the only usefull way of using stubs like that I could think of, so I hope that is what you want.

Answer 3

Maybe you could go with classes that extend the stubbed classes:

public class Stubber extends StubbedClass {
  public OobResponse RequestOobRequest(
    String ClientName,
    String SecurityLink,
    short LenofHHU,
    RequestMode RequestMode) {
      OobResponse oobr = new OobResponse();
      return oobr;
    }
} 

If you cant create an OobResponse, you could similarly create a public class OobResponseStub extends OobResponse