Комментарии 12
Статья отличная, но картинка — тяжелейшая форма депрессии.
Это из иллюстрации к корнею чуковскому. Для вас это бред, а для нас (постарше) это тест на школоло )) шутка, без обид.
А если серьезно то тк автору у меня вопросы
непонятно зачем так реализовывать модуль к фреймворку тестирования (у вас гольный junit или как?)
Стал ли этот вспомогательный код частью приложения?
Не похоже ли это на антипаттерн тестирование моков?
А если серьезно то тк автору у меня вопросы
непонятно зачем так реализовывать модуль к фреймворку тестирования (у вас гольный junit или как?)
Стал ли этот вспомогательный код частью приложения?
Не похоже ли это на антипаттерн тестирование моков?
hanovruslan, под вспомогательным кодом вы имеете ввиду SimpleAerospikeClient.java? Это, скажем так, упрощенная версия того, что используется в приложении.
Не совсем понял про тестирование моков, ведь идея как раз в том, чтобы написать интеграционный тест. Тест, который, в данном случае, будет проверять взаимодействие приложения с базой данных: как минимум, правильно ли вы настроили клиент для работы с базой, правильно ли выбрали структуру данных для хранения, и т.д.
Не совсем понял про тестирование моков, ведь идея как раз в том, чтобы написать интеграционный тест. Тест, который, в данном случае, будет проверять взаимодействие приложения с базой данных: как минимум, правильно ли вы настроили клиент для работы с базой, правильно ли выбрали структуру данных для хранения, и т.д.
zeliboba69
Да, про тестирование моков я немного не в тему сказал. Задам другой вопрос ) не знаю как там в джава, но в php есть варианты проще перехватывать подобные обращения (у вас их к слову нет, вы поднимаете какой-то инстанс нужного сервиса) — SoftMocks или runkit. это инструменты которые перегружают библиотечные (недоступные в исходном виде) модули\функции, чтобы обеспечить как и в вашем случае — интеграционные тесты. Так вот привлечение докера (только для интеграционных тестов?) так как-бы немного сбоку смотрится странным решением.
Может быть следует сделать сборку на docker-compose для нескольких окружений (dev, test, prod) где не потребуется использовать SimpleAerospikeClient а взаимодействие клиентов и их серверами будет обеспечено сетью, которую поднимает докер при запуске группы контейнеров? Это, скорее всего сложнее, но выглядит имхо канонично в рамках использования контейнеров
а еще что у вас с фреймворком тестирования? Это JUnit? А есть ему альтернативы?
Да, про тестирование моков я немного не в тему сказал. Задам другой вопрос ) не знаю как там в джава, но в php есть варианты проще перехватывать подобные обращения (у вас их к слову нет, вы поднимаете какой-то инстанс нужного сервиса) — SoftMocks или runkit. это инструменты которые перегружают библиотечные (недоступные в исходном виде) модули\функции, чтобы обеспечить как и в вашем случае — интеграционные тесты. Так вот привлечение докера (только для интеграционных тестов?) так как-бы немного сбоку смотрится странным решением.
Может быть следует сделать сборку на docker-compose для нескольких окружений (dev, test, prod) где не потребуется использовать SimpleAerospikeClient а взаимодействие клиентов и их серверами будет обеспечено сетью, которую поднимает докер при запуске группы контейнеров? Это, скорее всего сложнее, но выглядит имхо канонично в рамках использования контейнеров
а еще что у вас с фреймворком тестирования? Это JUnit? А есть ему альтернативы?
альтернатива JUnit, например, TestNG. Но зачем ему альтернативы? JUnit просто как автомат калашникова, там с десяток методов с общим смыслом assertTrue(message, desired, actual) и всё. Код JUnit'а простейший, можно допиливать его и допиливать как хочешь. Вроде, там просто нечего заменять, это и так минимальный минимум.
>Для использования Aerospike в интеграционных тестах, мы написали обертку для docker и docker-machine. Она умеет:
>Стартовать / останавливать контейнеры.
>Смонтировать конфигурационный файл aerospike.conf внутрь контейнера.
>Привязать порт контейнера к свободному порту хоста.
А почему не использовали для этого Chef?
>Стартовать / останавливать контейнеры.
>Смонтировать конфигурационный файл aerospike.conf внутрь контейнера.
>Привязать порт контейнера к свободному порту хоста.
А почему не использовали для этого Chef?
Как один из мэйнтейнеров проекта не могу не спросить:
А почему не http://github.com/testcontainers/testcontainers-java? :)
А почему не http://github.com/testcontainers/testcontainers-java? :)
Все просто: хоть статья и написана недавно, но данный подход мы используем с 2015 года когда проект TestContainers видимо только стартовал, ну и плюс все тесты в проекте на TestNG. Но библиотека у вас очень интересная, как минимум смотреть в её сторону имеет смысл!
https://github.com/testcontainers/testcontainers-java/issues/132 :)
На самом деле у нас тоже были тесты на TestNG, мы просто создавали контейнеры из TC и вручную вызывали .start() и .stop().
Как и написал выше, мы тоже начали со своего, а потом просто присоединились к TestContainers. OpenSource FTW! :)
Можете постучаться в разного рода IM-ы (Gitter, Skype ), я помогу смигрировать на TC если надо :)
На самом деле у нас тоже были тесты на TestNG, мы просто создавали контейнеры из TC и вручную вызывали .start() и .stop().
Как и написал выше, мы тоже начали со своего, а потом просто присоединились к TestContainers. OpenSource FTW! :)
Можете постучаться в разного рода IM-ы (Gitter, Skype ), я помогу смигрировать на TC если надо :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как нам помог Docker в написании тестов