2016-08-12 5 views
3

Я пишу модульное тестирование для статического метода полезности:тесты Android написания блока для служебных методов

public static String getString(Object object, boolean prettyPrint) { 
    if (object == null) { 
     throw new NullPointerException("Cannot pass null to Utility.getString() method"); 
    } 
    Gson gson; 
    if (prettyPrint) { 
     gson = new GsonBuilder().setPrettyPrinting().create(); 
    } else { 
     gson = new Gson(); 
    } 
    return gson.toJson(object); 
} 

Вот тест блока:

@Test 
public void getString() throws Exception { 
    JokeItem item = new JokeItem("title", "joke"); 
    String required = new Gson().toJson(item); 
    String actual = Utility.getString(item, false); 
    Assert.assertEquals(required, actual); 
    String required1 = "{\"joke\":\"joke\",\"title\":\"title\"}"; 
    String actual1 = Utility.getString(item, false); 
    Assert.assertEquals(required1, actual1); 
} 

JokeItem простого класс POJO. Проблема, с которой я сталкиваюсь, заключается в том, что я не уверен, что мой тестовый пример, если правильный способ проверить этот метод, потому что я в основном использую тот же метод gson.toJson(object) в обоих методах. Было бы очень полезно, если бы я мог получить некоторые сведения о тестировании такие функции, ловушки и недостатки в моем подходе.

+0

Если вы используете «gson» от Google, почему вы его тестируете? Я только проверяю код, который я могу активно изменять/рефакторировать и полагаться при использовании сторонних библиотек для соответствующего разработчика, чтобы самим протестировать их. Единственное отклонение - это когда я сам обнаруживаю ошибки в библиотеке и хочу это доказать. – Smutje

+0

Правильный способ - сделать новый Gson(). ToJson (item); 'потому что, когда у вас больше свойств в вашем' JokeItem', вам, вероятно, потребуется изменить ur custom i.e 'required1' – Smit

ответ

3

Тестирование таких методов на самом деле довольно просто - вы создаете серию тестов, которые вызывают метод с определенным входом; и затем вы проверяете, что возвращается. Нравится:

@Test(expected=NullPointerException.class) 
public testCtorWithNullStringAndTrue() { 
    Whatever.getString(null, true); 
} 
// same for false 

// and then 
public testSomeInput() { 
    assertThat(Whatever.getString("whatever", true), is("expected-json-string")); 
} // same for false ... 

Возможно, вам не понадобится гораздо больше, чем это, как указал Марек; вам не следует начинать реализацию Gson.

Но: вы определенно хотите проверить все возможные пути в вашем методе; в вашем случае вы просто хотите удостовериться, что вы вернете какой-то ожидаемый результат для определенного фиксированного ввода (включая все разные «недопустимые» данные!).

Наконец, по качеству кода: заманчиво писать такие маленькие помощники, как статические методы; и использовать логическое значение как аргумент, , но ... это неплохой дизайн OO. Рассмотрим это:

interface JsonBuilder { 
    String getString(Object input); 
} 

class SimpleBuilder implements JsonBuilder 
// does what your "non-pretty print code" does 

class PrettyBuilder implements JsonBuilder 
// does the other thing 

И вместо того, чтобы беспокоиться об использовании true/false; и плотно связывают пользователей этого статического метода с реализацией (трудно сломать позже); вы можете просто обходить объекты интерфейса JsonBuilder. И ваш код просто вызывает этот метод, не беспокоясь.

Может быть, перебор, но все же подход, о котором стоит подумать.

3

Единичное тестирование Gson не имеет смысла - оно уже проверено его авторами.
Как ваш метод довольно прост, я бы сказал, что только первый оператор if должен быть проверен и проверен, если при передаче нулевого объекта выбрано NullPointerException.
Если вы хотите создать более сильный тест, я бы предложил проверить взаимодействия с Gson и GsonBuilder, чтобы проверить, были ли выведены правильные методы. Но это потребует шпионажа на оба объекта.

Смежные вопросы