Mockist tdd: Как проверить UUT, когда соавтор может быть создан только внутри UUT? - PullRequest
Новая
       32

Mockist tdd: Как проверить UUT, когда соавтор может быть создан только внутри UUT?

2 голосов
/ 12 марта 2012

Я пытаюсь поведенчески протестировать объект Java с именем StringReader. Код выглядит примерно так: 

public interface CharReader {
  public char readChar();
}    

public class ByteArrayCharReader implements CharReader {
  public ByteArrayCharReader(byte[] bytes);
  public char readChar();
}

public class StringReader {
  public String readString(byte[] bytes);
}

Протокол / ответственность StringReader:

  • Когда вызывается readString, StringReader должен повторно вызывать CharReader.readChar () для чтения символа из байтового массива, пока не встретится нулевой символ завершения или максимальное количество символов, равное 20. Идея состоит в том, что StringReader не должен возиться со всеми неотъемлемыми элементами правильного декодирования символов Юникода, и такая ответственность возлагается на CharReader.

Я хочу написать модульный тест для StringReader, который выражает этот протокол, но я не могу понять, как.

Сначала я подумал, что я просто хотел, чтобы StringReader внутренне создал ByteArrayCharReader и использовал его в байтовом массиве, который передается в readString (), но, похоже, это не имеет смысла, так как тогда я не смогу издеваться над ним извне .

Тогда, похоже, у меня какая-то проблема с яйцом и курицей. Я хочу внедрить ByteArrayCharReader в StringReader, но ByteArrayCharReader должен быть создан с байтовым массивом, который доступен только в первый раз, когда вызывается readString - так как я могу передать его, если я не могу создать / смоделировать его извне ?. Это кажется глупой проблемой, потому что в теории я знаю, что байтовый массив, переданный в readString, на самом деле происходит из теста, откуда также берется ByteArrayCharReader, поэтому у меня есть готовые параметры "там". Может я что то пропустил?

Я должен упомянуть, что я работаю на базе устаревшего кода, и поэтому я не могу легко изменить интерфейс StringReader.readString.

Я немного расстроен, я не понимаю, как это решить, потому что это кажется очень простым сценарием; А передается массив и хочет проанализировать массив с ArrayParser - как проверить это поведенчески (не на основе состояния)?

1 Ответ

2 голосов
/ 12 марта 2012

Вы можете использовать шаблон фабричного метода .Вместо внедрения / создания экземпляра ByteArrayCharReader вы просто внедряете фабрику, задача которой состоит в том, чтобы предоставлять экземпляры запрашиваемых читателей: 

public class ReadersFactoryImpl implements ReadersFactory {
    public CharReader CreateByteReader(byte[] content) {
        return new ByteArrayCharReader(content);
    }
}

Вот и все.Вы можете легко смоделировать это и настроить так, чтобы он возвращал еще одну насмешку.Этого должно быть достаточно, чтобы проверить, вызывает ли StringReader другой читатель, как ожидается.

...