Статьи

PODAM — Сбор требований

Январь 7, 2019

Как было объявлено в моей предыдущей статье, я начинаю новый проект, предоставляющий простой API для заполнения POJO фиктивными данными.

Цель этой статьи — собрать первый черновик требований для PODAM. Итак, что нужно инструменту для заполнения POJO фиктивными данными?

  1. Инструмент должен предоставлять черный ящик через простую функцию: заданный в качестве аргумента класс POJO, функция ДОЛЖНА возвращать экземпляр класса POJO со всеми его переменными экземпляра, заполненными данными, если иное не указано в пользовательской аннотации (см. Следующий пункт) ,
  2. Возможность с помощью аннотаций настроить поведение такого инструмента. Например, можно пропустить автоматическую генерацию данных для некоторых атрибутов POJO; или кто-то может захотеть запустить значения, назначенные POJO: например, для числового атрибута значение, назначенное инструментом, должно быть в диапазоне от 5 до 100. Другие настройки могут идти в направлении точного присвоения значений свойствам (логическое значение, дата , и т.д)
  3. Возможность интеграции с такими инструментами, как JUnit, хотя PODAM не должен расширять JUnit, а JUnit может использовать PODAM посредством композиции. В этом сценарии вместо вызова функции Factory, которая возвращает экземпляр POJO, можно объявить аннотацию @Podam для (экземпляра) локальной переменной в тесте JUnit (или другой инфраструктуры тестирования), и затем будет вызван метод factory , 
  4. Чтобы PODAM работал, POJO, устанавливаемый с фиктивными данными, должен иметь конструктор без аргументов

Попробуем захватить вышеуказанные требования по шагам. Давайте начнем с самого простого сценария, например, я хочу, чтобы POJO со всеми его атрибутами (включая объекты графа) был установлен с некоторыми фиктивными значениями. Учитывая следующую модель домена:

 

Пример модели домена PODAM

 Клиент имеет адрес и один или несколько банковских счетов. Если я пишу тест JUnit для сервиса, который использует клиентский POJO, я бы хотел, чтобы PODAM предложил что-то вроде этого:

public class ClientServiceUnitTest {

  @JUnit

  public void testClientService() throws Exception {

    ClientService service = EasyMock.createMock(ClientService.class);

    Client clientDto = PodamFactory.createDummy(Client.class);

    service.persistClient(clientDto);

    EasyMock.expectLastCall();

    //Etc. Replay and Mock validation

  }

}

PodamFactory должен возвращать клиентский POJO, чьи атрибуты примитивных типов заполнены значениями, а также чьи графические объекты заполнены данными. Таким образом, у клиента будет объект адреса, заполненный фиктивными данными и набором одного или нескольких банковских счетов.

Теперь давайте посмотрим на еще несколько интересных сценариев. Допустим, я хотел, чтобы клиентский POJO был заполнен данными, но я хотел, чтобы атрибут адреса был пропущен. Я мог бы написать что-то вроде следующего:

//Imports omitted

public class Client implements Serializable {

  private String firstName;

  private String lastName;

  @Podam(skip=true)  private Address address;

  private List<BankAccount> bankAccounts;

  //Constructors, getters/setters, equals/hashcode and toString methods omitted for brevity

}

 Я мог бы использовать аннотацию @Podam с логическим атрибутом skip = true, чтобы указать, что PODAM не должен заполнять определенный атрибут. Конечно, чтобы графические объекты были заполнены фиктивными данными, они должны быть PODAM-совместимыми (например, иметь конструктор без аргументов).

Другой сценарий может состоять в том, что я хотел указать, сколько именно банковских счетов я хотел. используя тот же класс, что и раньше, я мог бы иметь:

//Imports omitted

public class Client implements Serializable {

  private String firstName;

  private String lastName; 

  private Address address;

  @Podam(nbrElements=5)

  private List<BankAccount> bankAccounts;

  //Constructors, getters/setters, equals/hashcode and toString methods omitted for brevity

}

Используя атрибут nbrElements, я мог указать PODAM, сколько элементов в списке я бы хотел заполнить фиктивными данными. Таким образом, похоже, что аннотация @Podam возникает из начальных требований. Вопрос в том, будет ли такая аннотация (которая относится в основном к миру тестирования) приемлемой в рабочем коде POJO. Я считаю, что аннотации в целом безвредны и что преимущества точного контроля над автоматически генерируемыми фиктивными данными во время тестирования перевешивают недостатки, связанные с импортом, связанным с тестированием, в нашем коде.

Посмотрим, смогу ли я определить некоторые атрибуты аннотации @Podam.

  • пропускать. (Boolean). Он инструктирует инструмент, чтобы пропустить автоматическую генерацию фиктивных данных для аннотированного атрибута. По умолчанию установлено значение false. 
  • значение. (String). Он просит инструмент назначить точно значение, указанное в атрибуте. По умолчанию используется пустая строка.
  • MinValue. (Числовой). Требуется, чтобы инструмент присваивал аннотированному атрибуту числовое значение, которое не должно быть меньше значения, определенного в аннотации.
  • MaxValue. (Числовой). Аналогичен minValue, за исключением того, что значение, назначенное аннотированному атрибуту, не должно превышать значение, указанное в аннотации. По умолчанию используется максимальное значение для типа аннотированного атрибута.
  • nbrElements. В случае коллекции — количество элементов, которые инструмент должен создать с фиктивными значениями. По умолчанию это 1.
  • длина. (Числовой). Длина фиктивного строкового значения, назначенного аннотированному атрибуту. Значением по умолчанию может быть произвольное число, например 5, 10, 20 и т. Д.

Пока это те качества, о которых я мог подумать. Как вы думаете, ребята?

 

От http://tedone.typepad.com/blog/2011/03/podam-gathering-requirements.html

40
Share: