Как записать, что jUnit тестирует на класс, который использует сетевое соединение

В качестве альтернативы полезному ответу Фингласа относительно насмешек рассмотрим заглушенный подход, при котором мы переопределяем функциональность callWebsite (). Это работает довольно хорошо в случае, когда нас не так интересует логика callWebsite, как логика другой логики, вызываемой в pushEvent (). Важно проверить, что callWebsite вызывается с правильным URL-адресом. Итак, первое изменение заключается в том, чтобы сигнатура метода callWebsite () стала:

protected String callWebsite(String url){...}

Теперь мы создаем заглушенный класс следующим образом:

class MyClassStub extends MyClass {
    private String callWebsiteUrl;
    public static final String RESPONSE = "Response from callWebsite()";

    protected String callWebsite(String url) {
        //don't actually call the website, just hold onto the url it was going to use
        callWebsiteUrl = url;
        return RESPONSE;
    }
    public String getCallWebsiteUrl() { 
        return callWebsiteUrl; 
    }
}

И, наконец, в нашем тесте JUnit:

public class MyClassTest extends TestCase {
    private MyClass classUnderTest;
    protected void setUp() {
        classUnderTest = new MyClassStub();
    }
    public void testPushEvent() { //could do with a more descriptive name
        //create some Event object 'event' here
        String response = classUnderTest.pushEvent(event);
        //possibly have other assertions here
        assertEquals("http://some.url", 
                     (MyClassStub)classUnderTest.getCallWebsiteUrl());
        //finally, check that the response from the callWebsite() hasn't been 
        //modified before being returned back from pushEvent()
        assertEquals(MyClassStub.RESPONSE, response);
    }
 }

Создайте абстрактный класс WebsiteCaller который будет родительским для ConcreteWebsiteCaller и WebsiteCallerStub .

Этот класс должен иметь один метод callWebsite (String url) . Переместите свой метод callWebsite из MyClass в ConcreteWebsiteCaller . И MyClass будет выглядеть так:

class MyClass {

    private WebsiteCaller caller;

    public MyClass (WebsiteCaller caller) {
        this.caller = caller;
    }

    public String pushEvent (Event event) {
        //do something here
        String url = constructURL (event); //construct the website url
        String response = caller.callWebsite (url);

        return response;
    }
}

и реализовать метод callWebsite в вашем WebsiteCallerStub некоторым образом подходящим для тестирования.

Затем в модульном тесте сделайте что-нибудь вроде этого:

@Test
public void testPushEvent() {
   MyClass mc = new MyClass (new WebsiteCallerStub());
   mc.pushEvent (new Event(...));
}

Заглушка

Вам понадобится тестовый двойной (заглушка), позволяющий изолированное, простое, модульное тестирование. Следующее не проверено, но демонстрирует идею. Использование внедрения зависимостей позволит вам внедрить во время тестирования тестовую версию вашего HttpURLConnection.

public class MyClass() 
{
   private IHttpURLConnection httpUrlConnection;   

   public MyClass(IHttpURLConnection httpUrlConnection)
   {
       this.httpUrlConnection = httpUrlConnection;
   }

   public String pushEvent(Event event) 
   {
       String url = constructURL(event);
       String response = callWebsite(url);
       return response;
  }
}

Затем вы создаете заглушку (иногда называемую имитацией объекта), которая будет заменять конкретный экземпляр.

class TestHttpURLConnection : IHttpURLConnection { /* Methods */ }

Вы также создадите конкретную версию для использования в производственном коде.

class MyHttpURLConnection : IHttpURLConnection { /* Methods */ }

Используя свой тестовый класс (адаптер ), вы можете указать, что должно произойти во время вашего теста. Фреймворк для имитации позволит вам сделать это с меньшим количеством кода, или вы можете подключить его вручную. Конечным результатом этого для вашего теста является то, что вы установите свои ожидания для своего теста, например, в этом случае вы можете настроить OpenConnection для возврата истинного логического значения (это, кстати, всего лишь пример). Затем ваш тест подтвердит, что, когда это значение истинно, возвращаемое значение вашего метода PushEvent соответствует некоторому ожидаемому результату. Я какое-то время не касался Java должным образом, но вот несколько рекомендуемых фреймворков для имитации , как указано членами StackOverflow.

Подходя к вещам под немного другим углом ...

Я бы меньше беспокоился о тестировании этого конкретный класс. Код в нем чрезвычайно прост, и хотя функциональный тест, чтобы убедиться, что он работает с подключением, был бы полезен, тест на уровне модулей «может» не понадобиться.

Вместо этого я бы сосредоточился на тестировании вызываемых им методов, которые действительно что-то делают. В частности ...

Я бы протестировал метод constructURL из этой строки:

String url = constructURL (event);

, убедившись, что он может правильно построить URL-адрес из разных событий и выдает исключения, когда это необходимо (возможно, при недопустимом событии или нулевом значении).

И я бы протестировал метод из следующей строки:

String responseMessage = responseParser.getResponseMessage (connection);

Возможно, вытащил любую логику «получить информацию из соединения» в одну процедуру и оставил только «проанализировать указанную информацию» в исходной:

String responseMessage = responseParser.getResponseMessage(responseParser.getResponseFromConnection(connection));

Или что-то вдоль этих линий.

Идея состоит в том, чтобы поместить любой код «должен иметь дело с внешними источниками данных» в один метод, а любую логику кода - в отдельные методы, которые можно легко протестировать.