Согласно DI вообще не нужно создавать инстансы вручную. Просто соглашение, что все зависимости в коде не создаются, а тянутся извне через аннотацию @Inject, т.е. примерно так:
@javax.inject.Singleton
public class MyFirstClass {… }
Честно — не знаю как именно. Я просто верю контейнеру (spring/guice/jee), что он делает этот синглтон правильно. Никаких проблем не было, так что я особо и не вникал
Если вы не хотите признавать, что есть проблема в терминологии, не признавайте. Но лично я
а) Не хочу тестировать все моками для TDD
б) Не хочу признавать, что я делаю TDD на интеграционных тестах
в) mini-integration — это уже что-то странное. Хотя возможно имеет право на жизнь. Тут еще подсказывают, что такие тесты по сути спеки BDD.
Собственно я не написал, но весь сыр-бор классификации в том, что только юнит-тесты применимы для TDD, так как запускать integrational тесты при каждой сборке или изменении в коде — идиотия. Может кто-то и делает TDD на интеграционных тестах, но это уже тема для другого спора :)
В общем годится и такая классификация: если можно разрешить запускать тест при сборке проекта и после каждого изменения — это юнит-тест. Если требуется спец-окружение и/или тест долгий — это интеграционный тест, и его запускать можно только из спецокружений вроде CI сервера.
Ну тут по ситуации смотреть. Если они критические, то нужно уже либо на in-memory переходить, либо не запускать этот тест при каждой сборке проекта, а запускать как интеграционный через сервер CI, например.
Если база MySQL стоит на том же хосте, ее схема перед каждым тестом создается с нуля, то тест так же назову юнит-тестом. Если на другом хосте — получаем зависимость от сети (сеть может лагать, сеть может лежать) — интеграционные тест.
Как раз на основании той фразы, что вы мне наверное хотели написать: In essence classic xunit tests are not just unit tests, but also mini-integration tests.
Здесь я подразумеваю, что mini-integration != integration
Базу в памяти создает и наполняет наше приложение. Причем перед каждым запуском. Фактически база является некой производной от кода. Состояние продакшен базы нам неизвестно и неподконтрольно, поэтому результат теста зависит от ее состояния.
Видите ли я не вижу принципиальной разницы между классом-сервисом, который внутри зависит от in-memory базы от класса-стека, который внутри использует скажем, класс-Integer для подсчет элементов с точки зрения тестов. Поэтому тест и для первого и для второго я называю юнит-тестом.
>A unit is the smallest testable part of an application
Ну ок, у меня веб-сервис как раз smallest testable part, потому как если тесты сформированы в терминах http-вызовов, то менее тестируемой части у меня нет.
«The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn't really matter that much.
A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service.»
Т.е. он констатирует, что есть два сложившихся подхода к написанию тестов. И моки — не единственный подход.
1) Глупо писать новый проект на Java < 1.5 :)
2) Проектов на < 1.5 все меньше и меньше
С уважением, КЭП.
@javax.inject.Singleton
public class MyFirstClass {… }
@javax.inject.Singleton
public class MySeconfClass {
@Inject private MyFirstClass obj;
}
@javax.inject.Singleton
public class MyFirstClass {… }
@javax.inject.Singleton
public class MyClass {… }
:)
а) Не хочу тестировать все моками для TDD
б) Не хочу признавать, что я делаю TDD на интеграционных тестах
в) mini-integration — это уже что-то странное. Хотя возможно имеет право на жизнь. Тут еще подсказывают, что такие тесты по сути спеки BDD.
В общем годится и такая классификация: если можно разрешить запускать тест при сборке проекта и после каждого изменения — это юнит-тест. Если требуется спец-окружение и/или тест долгий — это интеграционный тест, и его запускать можно только из спецокружений вроде CI сервера.
Здесь я подразумеваю, что mini-integration != integration
Ну ок, у меня веб-сервис как раз smallest testable part, потому как если тесты сформированы в терминах http-вызовов, то менее тестируемой части у меня нет.
A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service.»
Т.е. он констатирует, что есть два сложившихся подхода к написанию тестов. И моки — не единственный подход.