Спасибо за интересную статью! Скажите, какие виды тестов у вас пишут разработчики, а какие QA? И заменяются ли моками другие микросервисы в интеграционных тестах? Если нет, то бывают ли проблемы, когда тесты падают из-за проблем на стороне сервисов, за которые отвечает другая команда?
У меня есть успешный опыт работы по TDD, но не уверен, что адепты воспримут такой подход "трушным". Но лично мне он полезен: действительно ускоряет и упрощает рефакторинг. Для себя эмпирическим путем вывел несколько правил:
Лучше всего писать по TDD код, реализующий бизнес-логику. Инфраструктурный код, контроллеры, UI и прочее поддается хуже; в этих случаях я не пытаюсь в TDD
Как следствие предыдущего пункта, для работы по TDD в приложении уже должна быть кое-какая инфраструктура, готовая к тестированию; писать по TDD с нуля не особо заходит
Перед написанием тестов нужно определить их тип. Я разделяю юнит- и интеграционные тесты. Чтобы не увязнуть в моках, следую правилу - если в модуле нет зависимостей от внешних ресурсов, то пишется юнит тест (соответственно, юнит тесты никогда не содержат моков); иначе пишется интеграционный тест, в котором моками заменяются только внешние зависимости, которые невозможно/неудобно поднимать локально (например, СУБД всегда использую реальную)
Хотелось бы узнать побольше про разделение «чистого кода» и «грязного рантайма»: как они связываются, как выглядят описания DB или HTTP -запросов, что в такой архитектуре происходит с DI.
Материала, как мне кажется, на ещё одну статью, был бы очень рад прочитать
В последнее время популярность языков программирования определяю очень просто — беру популярную площадку с вакансиями (для нас hh, для США Dice) и пробиваю в поиске названия языков. По количеству вакансий можно определить наиболее востребованные языки.
Так вот Python как раз попал в топ-3 (и даже топ-2). Возьмём, к примеру, вакансии на Dice в Калифорнии:
1. Java: 2,428
2. Python: 1,798
3. JavaScript: 1,163 (из них около 400 на NodeJS)
4. C: 834 (в выборку попали вакансии, совмещённые с C++)
5. C++: 771 (в выборку попали вакансии, совмещённые с C)
6. C#: 639
7. PHP: 295 (кто писал про популярность PHP?)
8. Swift: 151
Спасибо за интересную статью! Скажите, какие виды тестов у вас пишут разработчики, а какие QA? И заменяются ли моками другие микросервисы в интеграционных тестах? Если нет, то бывают ли проблемы, когда тесты падают из-за проблем на стороне сервисов, за которые отвечает другая команда?
У меня есть успешный опыт работы по TDD, но не уверен, что адепты воспримут такой подход "трушным". Но лично мне он полезен: действительно ускоряет и упрощает рефакторинг. Для себя эмпирическим путем вывел несколько правил:
Лучше всего писать по TDD код, реализующий бизнес-логику. Инфраструктурный код, контроллеры, UI и прочее поддается хуже; в этих случаях я не пытаюсь в TDD
Как следствие предыдущего пункта, для работы по TDD в приложении уже должна быть кое-какая инфраструктура, готовая к тестированию; писать по TDD с нуля не особо заходит
Перед написанием тестов нужно определить их тип. Я разделяю юнит- и интеграционные тесты. Чтобы не увязнуть в моках, следую правилу - если в модуле нет зависимостей от внешних ресурсов, то пишется юнит тест (соответственно, юнит тесты никогда не содержат моков); иначе пишется интеграционный тест, в котором моками заменяются только внешние зависимости, которые невозможно/неудобно поднимать локально (например, СУБД всегда использую реальную)
Хотелось бы узнать побольше про разделение «чистого кода» и «грязного рантайма»: как они связываются, как выглядят описания DB или HTTP -запросов, что в такой архитектуре происходит с DI.
Материала, как мне кажется, на ещё одну статью, был бы очень рад прочитать
Так вот Python как раз попал в топ-3 (и даже топ-2). Возьмём, к примеру, вакансии на Dice в Калифорнии:
1. Java: 2,428
2. Python: 1,798
3. JavaScript: 1,163 (из них около 400 на NodeJS)
4. C: 834 (в выборку попали вакансии, совмещённые с C++)
5. C++: 771 (в выборку попали вакансии, совмещённые с C)
6. C#: 639
7. PHP: 295 (кто писал про популярность PHP?)
8. Swift: 151