Я считаю что нет )
Оки, имеет место быть :)
Павел
Павел
Но я не "За" :)
Юра
Уже говориг тут что тесты апи не привязаны к языку, в теории можно переписать бекенд на облако, другой язык, вотевер и тесты апи останутся без изменений почти
Павел
Уже говориг тут что тесты апи не привязаны к языку, в теории можно переписать бекенд на облако, другой язык, вотевер и тесты апи останутся без изменений почти
Это да, но например есть апи под капотом который сложны функционал расчетов есть. Всегда приятнее писать, править и тестировать этот функционал в юните. Это прям по практике, а не по теории говорю
The Ant
Уже говориг тут что тесты апи не привязаны к языку, в теории можно переписать бекенд на облако, другой язык, вотевер и тесты апи останутся без изменений почти
с другой стороны в процессе активной разработки апи может меняться каждый день, или даже по несколько раз в день. Стоит ли писать тесты тогда?
Павел
с другой стороны в процессе активной разработки апи может меняться каждый день, или даже по несколько раз в день. Стоит ли писать тесты тогда?
В жопу тесты и программирование, пойду проституткой (с)
Юра
Юра
Если апи меняется каждый день значит плохо спланировали и продумали
Юра
Или ты работаешь в снг конторе
Юра
Если это стартап и снг я говорю сразу забудьте про тесты пока
Юра
Пилите свой МВП и не мучайте разрабов
Павел
Наверное все же с функциональным я погорячился, все же это более высокоуровненовое наверное. Но как оказалось еще есть компонентное тестирование, чето даже не слыхал о таком. Вон оно вроде больше подходит под жизненный цикл коровы ) С другой стороны их часто (по статьям) объединяют под юниты.
Dmitry
У нас теория тестирования дробится на фреймворки? Фрейморки диктуют правила? Не знал.
Ну вот такая теория тестирования со своей классификацией.
Есть требования к софту:
- функциональные (логика кейсов)
- нефункциональные (производительность, безопасность)
Так что и тесты к ним:
- функциональные
- нефункциональные
Тестировать можно по размеру:
- функцию
- объект
- систему объектов
- всё приложение изнутри
- сервер с приложением снаружи
- систему приложений
По взаимодействию:
- изолированно
- в интеграции
Внешние тесты ещё можно называть:
- приёмочными для приёмки продукта
- end-to-end для эмуляции работы конечного пользователя с продуктом
Снаружи можно:
- дёргать API curl-ом
- проверять управляемым браузером
Из этого и получаем комбинаторику.
Как назвать функциональный тест сервиса из контейнера в интеграции с БД? Непонятно.
Как назвать функциональный тест всего приложения, где мы изнутри дёргаем контроллер, но в котором мы подсунули мок или стаб для изоляции от БД? Тоже непонятно.
Как назвать изолированный функциональный тест одного юнита? Вроде юнит-тестом. Но какой размер юнита?
Как назвать изолированный функциональный тест связки из пяти юнитов? Вроде интеграция, но без БД. Тоже непонятно.
Отсюда и сложность называния. И каждый фреймворк делает по-своему.
Павел
Ну вот такая теория тестирования со своей классификацией.
Есть требования к софту:
- функциональные (логика кейсов)
- нефункциональные (производительность, безопасность)
Так что и тесты к ним:
- функциональные
- нефункциональные
Тестировать можно по размеру:
- функцию
- объект
- систему объектов
- всё приложение изнутри
- сервер с приложением снаружи
- систему приложений
По взаимодействию:
- изолированно
- в интеграции
Внешние тесты ещё можно называть:
- приёмочными для приёмки продукта
- end-to-end для эмуляции работы конечного пользователя с продуктом
Снаружи можно:
- дёргать API curl-ом
- проверять управляемым браузером
Из этого и получаем комбинаторику.
Как назвать функциональный тест сервиса из контейнера в интеграции с БД? Непонятно.
Как назвать функциональный тест всего приложения, где мы изнутри дёргаем контроллер, но в котором мы подсунули мок или стаб для изоляции от БД? Тоже непонятно.
Как назвать изолированный функциональный тест одного юнита? Вроде юнит-тестом. Но какой размер юнита?
Как назвать изолированный функциональный тест связки из пяти юнитов? Вроде интеграция, но без БД. Тоже непонятно.
Отсюда и сложность называния. И каждый фреймворк делает по-своему.
Видимо просто функциональность из другой оперы, как вы и отметили в начале.
Функциональным может быть и юнит, когда решается какая то конкретная задача описанная бизнесом, потому что бизнес не описывает методы, а описывает функционал.
Так и интеграционные могут быть функциональными. Когда опять таки решается конкретная задача.
Функциональные тесты даже в пирамиде не нашел.
Павел
В итоге наверное да, тестирование коровы - будет юнит/компонент тестирование. Но возможен разный подход через белый и черный ящик - а тут уже холивар.
Юра
Главное чтобы баги в прод не пролезали
Юра
Прод дривен тестирование )
The Ant
как же хорошо все таки в веб деве, прям так простенько. уютненько, лампово.
В геймдеве сраную корову устанешь тестировать 😄
The Ant
Ну и это, раз уж начали проводить параллели с реального мира, то боженька и корова производитель другой коровы при рождении и в процессе жизнедеятельности не тестируется :D
Работает с заданными параметрами и немного добавляется в процессе обучения.
Проще говоря, тесты для гомосексуалистов 😄
Юра
The Ant
в вебе действительно простенько. Написать аи коровы и протестировать её будет невероятно сложно
The Ant
в отличие от пары сервисов в вебе, которые кладут значение в бд
Юра
Ну судя по качеству последних ааа релизов типо киберпанка с тестами действительно тяжело в геймдеае
The Ant
допустим если писать симулятор фермы какой.
корова должна есть. пить. чего-то бояться. У нее есть предпочтения в еде. есть органы зрения, обоняния. И т.д. и т.п.
Есть куча ситуций, в которых эта корова поведет себя по разному. + заложить какой-то рандом, чтоли. Для характера. Да да, у коров есть характер! )
Dmitry
Видимо просто функциональность из другой оперы, как вы и отметили в начале.
Функциональным может быть и юнит, когда решается какая то конкретная задача описанная бизнесом, потому что бизнес не описывает методы, а описывает функционал.
Так и интеграционные могут быть функциональными. Когда опять таки решается конкретная задача.
Функциональные тесты даже в пирамиде не нашел.
Всё программируется под бизнес-требования. Код без задач и без функциональности не пишется. И юнит-тесты тестируют как раз бизнес-кейсы юнита чёрным ящиком в изоляции.
Это только от непонимания целей тестирования у программистов возникают заморочки с тестированием каждого поля или метода по отдельности или ковыряния якобы белого ящика рефлексий. В итоге получаются тесты, реально мало что проверяющие, и при этом хрупкие из-за рефлексии.
Павел
Всё программируется под бизнес-требования. Код без задач и без функциональности не пишется. И юнит-тесты тестируют как раз бизнес-кейсы юнита чёрным ящиком в изоляции.
Это только от непонимания целей тестирования у программистов возникают заморочки с тестированием каждого поля или метода по отдельности или ковыряния якобы белого ящика рефлексий. В итоге получаются тесты, реально мало что проверяющие, и при этом хрупкие из-за рефлексии.
Ну понимание /не понимание каждый считает для себя отдельно. Да тесты с рефлексией хрупче, но тест который юзает 5 методов - сложнее и проверяет кейс и не понятно что где сломались. Что минусы.
Dmitry
Ну понимание /не понимание каждый считает для себя отдельно. Да тесты с рефлексией хрупче, но тест который юзает 5 методов - сложнее и проверяет кейс и не понятно что где сломались. Что минусы.
Но тогда получится, что кормление протестировали и бег протестировали, а общий кейс загнанной коровы не протестирован
Dmitry
https://youtu.be/Oj8bfBlwHAg
Юра
Ну понимание /не понимание каждый считает для себя отдельно. Да тесты с рефлексией хрупче, но тест который юзает 5 методов - сложнее и проверяет кейс и не понятно что где сломались. Что минусы.
Почему непонятно. Пишешь в тесте текст ошибки что ожидалось что вышло и все
Юра
Вообще по-моему это обычная практика в юнит тестах что непонятно что произошло
Юра
Часто приходится смотреть комиты на изменения чтобы разобраться
Юра
Ведь изменения в одном месте приводят к падению теста в десятом месте
Юра
И баги в основном не из-за того что метод два плюс два не смог сделать, а из-за какого-то сочетания методов
Юра
Или не обработана какая-то крайняя ситуация
Dmitry
Ну понимание /не понимание каждый считает для себя отдельно. Да тесты с рефлексией хрупче, но тест который юзает 5 методов - сложнее и проверяет кейс и не понятно что где сломались. Что минусы.
> но тест который юзает 5 методов - сложнее и проверяет кейс и не понятно что где сломались
А если такого общего теста нет, то мы вообще не узнаем, что там что-то сломано.
Юра
Павел
> но тест который юзает 5 методов - сложнее и проверяет кейс и не понятно что где сломались
А если такого общего теста нет, то мы вообще не узнаем, что там что-то сломано.
Я не говорил что общий тест не нужен, но тестить детали методов через общий тест, это как тестить через апиху какие то узкие if внутри бл
Dmitry
Я не говорил что общий тест не нужен, но тестить детали методов через общий тест, это как тестить через апиху какие то узкие if внутри бл
5 тестов на детали кормления
5 тестов на детали бега
2 общих теста без деталей на жива или нет
Павел
5 тестов на детали кормления
5 тестов на детали бега
2 общих теста без деталей на жива или нет
Как я и говорил выше возможны комбинации + на тест одного ifa одного метода нужно запускать и прописывать весь кейс. А если добавилась что то новое в сам кейс, ещё один промежуточный метод. Или бег убрали а сделали другое. Переписывать все методы на тест кормежки, хотя сама кормежка не менялась ?
Павел
Свои минусы, как и я писал
artem
Как я и говорил выше возможны комбинации + на тест одного ifa одного метода нужно запускать и прописывать весь кейс. А если добавилась что то новое в сам кейс, ещё один промежуточный метод. Или бег убрали а сделали другое. Переписывать все методы на тест кормежки, хотя сама кормежка не менялась ?
Тут никто про TDD не читал?) Главное это тест. Реализация это cs
artem
Это же лучшее что придумали в разработке, кроме того что у тебя есть тест, так и перед реализацией ты уже знаешь бл
Павел
Тут никто про TDD не читал?) Главное это тест. Реализация это cs
Главное это тест - бизнес не зарабатывает на тестах.
Лучшее - тоже спорно, холивар.
artem
Главное это тест - бизнес не зарабатывает на тестах.
Лучшее - тоже спорно, холивар.
Да начнется холивар)) просто бизнесу нужно объяснить что на тестах разраб понимает бл, и заодно привлекать новых разрабов
Павел
artem
Я про тдд.
И я про тоже) у меня был проект где ба частично знал тестирование (нужно было ему только перевести), подвёл к компу: "так должно быть", да. И спокойно себе работаешь, никто не предявит
Павел
Да начнется холивар)) просто бизнесу нужно объяснить что на тестах разраб понимает бл, и заодно привлекать новых разрабов
Разраб и без тестов может понимать бл. Проекты и без тестов существуют, не то что tdd vs no-tdd
Павел
Короче безсмысленный разговор. Вам нравится тдд - пишите, есть подход кто спорит.
artem
Разраб и без тестов может понимать бл. Проекты и без тестов существуют, не то что tdd vs no-tdd
Тут сразу вспоминаю прикол что код нужно писать абсолютно непонятным чтобы тебя не уволили. А так, прочитал тесты и все понял
Павел
Dmitriy
выходить на более высокий уровень тестов, когда сеттеров и геттеров нет
писать функциональные тесты апишки, тогда можно смело рефакторить
The Ant
Тут сразу вспоминаю прикол что код нужно писать абсолютно непонятным чтобы тебя не уволили. А так, прочитал тесты и все понял
Прочитал тесты, прочитал код. И рабочий день закончился. Ну тоже нормально
artem
Прочитал тесты, прочитал код. И рабочий день закончился. Ну тоже нормально
Ну я же за идеальный мир говорю
Павел
Прочитал тесты, прочитал код. И рабочий день закончился. Ну тоже нормально
Не ну тесты реально помогают понимать как должно работать. Потому что в коде не видишь что должно быть на выходе.
The Ant
меня одного чтоли учили сначала рисовать блок схемы, потом писать код? :D
Павел
меня одного чтоли учили сначала рисовать блок схемы, потом писать код? :D
Ну блок схемы это тоже хорошо :) Я чисто говорю за тесты (вне тдд), что они реально помогают понять логику кода.
Павел
Хороший тест - как документация
The Ant
сорян, но какой-то набор штампов )
The Ant
вот реально хорошо помогает понимать логику это ручка и листочек. накидать схему
The Ant
а не тесты писать
Павел
сорян, но какой-то набор штампов )
Ну почему. Заходишь в тесты модуля там "TestPurchaseWithoutUserCashExpectException".
Просто был случай сказали - вот есть либа (точнее проект, а там модуль), выдрать оттуда. Зашел - нихера не понял толком как работает. Зашел в тесты - сразу все понятно что на входе что на выходе, надрал нужного из кода, не запуская. Сказал спасибо разработчику за тесты.
The Ant
если бы разработчик не был таким унылым гандоном, он бы написал в комментариях что тот или иной класс делает. Иначе говоря, документировал свой код адекватно.
The Ant
такое себе
Павел
The Ant
читаешь код в иде, наводишь мышкой на переменную и понимаешь что это, без читания говнотестов
The Ant
Понимаешь? )
Павел
Но я в душе не знаю что прилетает по api например, как это преобразуется, потом как попадает в мой модуль - в итоге что принимает, что отдает и в каком формате - хз
The Ant
документации к апи тоже нет? боже. А говоришь код хороший :D
Павел
документации к апи тоже нет? боже. А говоришь код хороший :D
Как коррелируется отсутствие сваггера и хороший код. Плюс для сваггера надо минимум проект запустить, я его даже не запускал
Павел
Я не пойму что ты хочешь доказать, что тесты не нужны?
Павел
Или что
The Ant
хороший код - документированный код, не?
The Ant
хорошо документированный код, это код, который читаешь не лазя в тесты ебучие
The Ant
чтобы понять что там происходит
Павел
хороший код - документированный код, не?
Хороший код, который почти не требует документация в виде комментов. А тесты - хорошая документция к коду, так как описывают юзкейсы и применение.
The Ant
Хороший код, который почти не требует документация в виде комментов. А тесты - хорошая документция к коду, так как описывают юзкейсы и применение.
заблуждение. держать проект даже на 10к строк в голове уже затруднительно
The Ant
уже молчу если туда лазишь раз в полгода
Павел
заблуждение. держать проект даже на 10к строк в голове уже затруднительно
Так а зачем его держать. Есть переменные и методы которые заменяют комментарии, а кейсы и необходимая логика - в тестах.
Павел
Опять таки в "идеальном мире"