TDD …, как?

Ваш раскол звучит разумно. Я бы посчитал две зависимости входными и выходными. Можете ли вы сделать их менее зависимыми от конкретного производственного кода? Например, вы можете заставить его читать из общего потока данных вместо сокета? Это облегчило бы передачу тестовых данных.

Создание возвращаемого значения было бы труднее смоделировать, и не может ли это быть проблемой в любом случае - достаточно ли проста логика для фактического заполнения результирующего объекта (после синтаксического анализа)? Например, это просто установка тривиальных свойств? Если это так, я не стал бы пытаться представить там фабрику и т. Д. - просто введите некоторые данные испытаний и проверьте результаты.

Во-первых, начните думать «тесты», множественное число, а не «тест», единственное число. Вы должны ожидать, чтобы написать больше, чем один.

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

Например, предположим, что у вас уже есть байтовый массив с двоичными данными, поэтому вам даже не нужно думать о сокетах. Все, что вам нужно написать, это что-то, что берет байт [] и возвращает экземпляр вашего объекта. Можете ли вы написать тест для этого?

Если у вас все еще есть умственный блок, опустите его еще на одну отметку. Предположим, что ваш байтовый массив все равно будет содержать только значения по умолчанию. Так что вам даже не нужно беспокоиться о разборе, просто возможность вернуть экземпляр вашего объекта со всеми значениями по умолчанию. Можете ли вы написать тест для этого?

Я представляю что-то вроде:

public void testFooReaderCanParseDefaultFoo() {
  FooReader fr = new FooReader();
  Foo myFoo = fr.buildFoo();
  assertEquals(0, myFoo.bar());
}

Это круто, верно? Вы только тестируете конструктор Foo. Но затем вы можете перейти на следующий уровень:

public void testFooReaderGivenBytesBuildsFoo() {
  FooReader fr = new FooReader();
  byte[] fooData = {1};
  fr.consumeBytes(fooData);
  Foo myFoo = fr.buildFoo();
  assertEquals(1, myFoo.bar());
}

И так далее ...

Разработка через тестирование? Итак, это означает, что вы должны начать с написания теста в первую очередь.

Напишите тест, который содержит код типа «как вы хотите использовать свой класс». Этот класс или метод, который вы собираетесь тестировать с помощью этого теста, еще даже не существует.

Например, вы могли бы сначала написать тест, подобный этому:

[Test]
public void CanReadDataFromSocket()
{
     SocketReader r = new SocketReader( ... ); // create a socketreader instance which takes a socket or a mock-socket in its constructor

     byte[] data = r.Read();

     Assert.IsTrue (data.Length > 0);
}

Например; Я просто делаю пример здесь. Затем, как только вы сможете читать данные из сокета, вы можете начать думать о том, как вы будете их анализировать, и написать тест, в котором вы используете класс 'Parser', который берет прочитанные вами данные, и выводит экземпляр вашего класса данных. и т.д ...