практически возможно ли сделать хороший TDD (или BDD) без использования какой-либо структуры DI в java?

Я не думаю, что вам нужны фреймворки DI для модульного тестирования - TDD существовала за много лет до того, как DI стало модой. А в случае кода, который сам не использует явную структуру DI, зачем вам использовать это для модульных тестов?

Конечно, фреймворки DI могут в некоторой степени упростить задачу. OTOH они делают это, помещая сложность в другое место. Я предпочитаю иметь автономные модульные тесты, и до сих пор я почти всегда обходился без инфраструктуры DI. Это часто требует рефакторинга моего тестового кода, а иногда даже его дублирования, но я могу с этим жить. И, как отметила @kostja, насмешливые фреймворки тоже очень помогают.

Проектирование с учетом тестируемости также важно - если класс сложно протестировать как таковой, лучше провести его рефакторинг, чем пытаться облегчить боль с помощью инфраструктуры DI.

Обратите внимание, что все это требует большой практики, а также изменения мышления и образа мышления. Все это требует времени и терпения ... чем больше вы успеваете, тем лучше становитесь :-)

вы можете фактически протестировать отдельное поведение в каждом тесте - только один тест подойдет для одной вашей проблемы.

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

Предполагается, что DI сокращает прямые зависимости, фактически упрощая имитацию и модульное тестирование. Может, вам не хватает фиктивной части? этот пост может прояснить ситуацию.

Конечно, это возможно. И легко. Например, предположим, что вы хотите протестировать следующий метод, который вызывает статические методы класса Database (статический фасад постоянства) и напрямую создает экземпляр SimpleEmail (из электронной почты Apache Commons):

public void doBusinessOperationXyz(EntityX data) throws EmailException
{
   List<EntityX> items = 
      Database.find("select x from EntityX x where x.xyz=?", data.getXyz());

   BigDecimal total = ...compute/obtain the value...
   data.setTotal(total);

   Database.persist(data);

   Email email = new SimpleEmail();
   email.setSubject("Notification about processing of ...");
   email.addTo(data.getCustomerEmail());
   email.setMsg("...some notification message...");
   email.send();
}

Этот метод можно протестировать отдельно от зависимостей Database и Email с помощью следующего модульного теста, используя JMockit. :

@Test
public void doBusinessOperationXyz() throws Exception
{
   final EntityX data = new EntityX(5, "abc", "5453-1");
   final List<EntityX> items = new ArrayList();
   items.add(new EntityX(1, "AX5", "[email protected]"));

   new Expectations()
   {
      @Mocked final Database unused = null;
      @NonStrict SimpleEmail email;

      {
         Database.find(withSubstring("select"), (Object[]) any); result = items;
         Database.persist(data);

         email.send(); times = 1;
      }
   };

   new MyBusinessService().doBusinessOperationXyz(data);
}

Обычно необходимо внедрять фиктивные объекты для зависимостей Database и Email, что приводит к более сложному решению. Имитируя / заменяя статические методы и конструкторы, мы можем вместо этого сохранить простой, естественный и элегантный дизайн.