На 300 страниц которая

научись юнит тесты писать и все

и вообще тестировщики не нужны

Смешно

ты ж сам питонист

Ребят, харе набрасывать.

Но у нас тестировщики другими задачами занимаются и к этому коду вообще не лезут, а его надо протестить, я и спрашиваю. Не хотел тебя отвлекать, по этому в лс не писал

чтоб нормально писать юниты надо понять как и писать и моки освоить

в общем-то все :)

а вообще если у вас есть QA, он тебе может сценарии накидывать, а ты просто в коде имплементь

Они другие проекты тестируют и либо там мобайл, либо фронт часть

ваш бэк не тестирует никто?

Моки я писал, ну, т.е. немного писать юнит тесты могу, но говорю же - не серьезно подходить не хочу

Не-а

(

: (

Вот и говорите после этого что питонисты более грамотные разработчики чем пхписты :)

ну с юнит-тестами примерно как с бэкапами

их либо не пишут, либо уже пишут

Тут дело не в грамотности, а в организации, да и юнит-тесты были написаны(подозреваю каряво, мною) под мои же скрипты и интерфейсы, но они переписываются, и на меня повесили задачу - покрыть новое - адекватными тестами. Да, у меня нет опыта в глубоком тестировании

на самом деле практически все фигачат юниты по наитию

По моему опыту хороший набор функциональных тестов даже лучше чем юниты

Ну, на кодварсе тоже приходится юнитьесты писать

у них разные цели

Да цель у них у всех одна - находить баги

У нас этот бэк не работает с фронтом вообще

Да цель у них у всех одна - находить баги

вообще нет

Базовые глупые ошибки вылавливаются на ура, при этом даже не обязательно как там внутри реализовано, какие классы, свойства и т.д.

юнит-тесты это формальное доказательство корреткной работы кода

юнит-тесты это формальное доказательство корреткной работы кода

Путем нахождения багов :)

юнит-тесты это формальное доказательство корреткной работы кода

Вообще нет

если у тебя одностраничник с 95% логики на бэке – удачи покрывать это функциональными тестами

Для формального доказательства нужно рассмтривать все состояние переменных программы и иметь очень сложную мат. модель, что быстро приводит к комбинаторному взрыву.

Для формального доказательства нужно рассмтривать все состояние переменных программы и иметь очень сложную мат. модель, что быстро приводит к комбинаторному взрыву.

да, поэтому ты доказываешь, что работает конкретная функция

если у тебя одностраничник с 95% логики на бэке – удачи покрывать это функциональными тестами

А в чем проблема?

Юнит тесты лишь тыкают единичные значения из огромной кучи, и если повезет то словят ошибку.

Юнит тесты лишь тыкают единичные значения из огромной кучи, и если повезет то словят ошибку.

классы эквивалентности для этого придумали

Это extract transfoarm load processes, я с ОЛАП работаю, там данные, получается мне нужно писать юниттесты под функции/интерфейсы и отдельно функциональные под воркеры, так?

Тесты, которые работают по принципу "повезет" - плохие тесты.

Я не в вебе работаю(относительно)

А в чем проблема?

если у тебя на бэке крутится огромная логика, которая никак на фронте не отображается, а отображается только единичный результат работы огромной машины, высокоуровневым е2е ты ее не покроешь

Ну, не сайты

если у тебя на бэке крутится огромная логика, которая никак на фронте не отображается, а отображается только единичный результат работы огромной машины, высокоуровневым е2е ты ее не покроешь

Покроешь.

Покроешь.

Нет.

классы эквивалентности для этого придумали

Ну ведь на классы эквивалентности не всегда можно разбить, да и кто это вообще делает в юнит тестах? Такие реально существуют?

Нет.

Окей, в чем проблема покрыть это e2e?

в том, что тебе нужно проверять сущности, о которых клиентская часть вообще не в курсе

Много новых слов, иду в гугл заполнять пробелы

У тебя есть входящие значения, ожидаемая цепочка взаимодействий и исходящие значения.

e2e проверяет _всю_ цепочку, а не только вход выход.

Клиентской части и не надо знать про все сущности, которые участвуют в тесте.

Ну, окей, выражусь иначе. Я сейчас делаю end to end тесты для сервиса, у которого клиентская часть не знает 90% того, что происходит под капотом.

Это вполне нормально тестируется.

Клиентской части и не надо знать про все сущности, которые участвуют в тесте.

Вот этим и удобно, легаси можно покрыть функциональными и рефакторить с меньшим количеством нервов

Ну, окей, выражусь иначе. Я сейчас делаю end to end тесты для сервиса, у которого клиентская часть не знает 90% того, что происходит под капотом.

дай пример е2е теста :) возникает мысль, что мы говорим о разных вещах

Классный холивар, как я понял и не понял: советов больше нет, пошел гуглить, спасибо Никита и Хотабыч

Клиентской части и не надо знать про все сущности, которые участвуют в тесте.

да, но это не значит, что тебе ее уровнем ниже не надо тестировать

отвалидировать все тестами верхнего уровня чрезвычайно дорого

товарищи, как вы относитесь с большим тестовым заданиям? к пример кейс - вы отправили резюме в небольшую компанию, работа в которой по каким то причинам вам очень интересна. в ответ вам присылают БОЛЬШОЕ тестовое задание так или иначе затрагивающее тестирование текущего проекта компании. это может быть: написать цикл кейсов охватывающих какую то функциональность, тестирование свежего билда перед релизом и описание багов, написание тестов для фичи, ну вы поняли. большое такое, часов на 20 задание. вы будете его делать? попросите ли денег за его выполнение, хотя бы символически? попытаетесь договорится о ином задании?

Не надо валидировать все, только обычные кейсы

Не надо валидировать все, только обычные кейсы

что такое обычный кейс? :)

А что такое "всё" ? :)

а часто вы просите денег за тестовое задание?

Я например пишу крошечный тест который открывает странички нашего приложения. Кода получается строчек на 70-100, зато во время работы бэка затрагивается работа 70% всех классов, и если хоть один из них как-то с ошибкой отработает, то все упадет с исключением.

а часто вы просите денег за тестовое задание?

я - никогда. прошу мнение общественности по данному вопросу

а часто вы просите денег за тестовое задание?

Зависит какое тестовое задание =)) один попросили выполнить тестовое задание, а там работы на неделю минимум

дай пример е2е теста :) возникает мысль, что мы говорим о разных вещах

Окей. Юзер с фронтенда заполнил форму отправки бабла, нажал кнопку "Отправить 20 BTC", оно ушло в бэк по апи, сложилось в базу и в очередь, прошло ещё через 2 сервиса, один который third party service, подождало пока оно подтвердиться в third party service, пошло обратно по цепочке очередей по сервисам, обновилось в базе, обновилось на фронтенде как completed.

ERROR: S client not available

я - никогда. прошу мнение общественности по данному вопросу

Если они сами не предложили заплатить, то имхо нафиг их

Окей. Юзер с фронтенда заполнил форму отправки бабла, нажал кнопку "Отправить 20 BTC", оно ушло в бэк по апи, сложилось в базу и в очередь, прошло ещё через 2 сервиса, один который third party service, подождало пока оно подтвердиться в third party service, пошло обратно по цепочке очередей по сервисам, обновилось в базе, обновилось на фронтенде как completed.

во, хороший кейс :) ты чекаешь каждый этап?

Да.

Единственное что на third party service нужен мок.

А в чем проблема чекать каждый этап?

проблемы нет, это дорого

Это не дорого, потому что каждый из этих этапов должен мониториться бизнес метриками, т.к. это жирный кусок бизнес логики и если что-то из этого проседает - мы должны знать.

Дальше тебе нужно только выдернуть нужный ивент из мониторинга и прочекать jsonы.

проблемы нет, это дорого

Ну это же намного дешевле чем написать 100500 юнит тестов там на каждый метод

Ну это же намного дешевле чем написать 100500 юнит тестов там на каждый метод

Это никак не отменяет юнит тестов.

Это не дорого, потому что каждый из этих этапов должен мониториться бизнес метриками, т.к. это жирный кусок бизнес логики и если что-то из этого проседает - мы должны знать.

это круто, что вы обложены метриками, но не все ими обложены :)

Юниты, функциональные и end to end тесты не заменяют друг друга от слова вообще.

ниразу не дешевле

это круто, что вы обложены метриками, но не все ими обложены :)

Мы ещё не обложены, мы активно это делаем.

Потому что когда продукт это сраный блэкбокс - не понятно, как вообще работать можно.

e2e могут час идти, при том что юниты на той же функциональности 3-5 минут

Юниты, функциональные и end to end тесты не заменяют друг друга от слова вообще.

Если я рефакторю классы, то какой смысл их вообще покрывать тестами? Написать тест и тут же удалить вместе с классом?

ну мы вот обложены вполне себе, но это не отменяет юнитов

но они не взаимо заменяемы

Если я рефакторю классы, то какой смысл их вообще покрывать тестами? Написать тест и тут же удалить вместе с классом?

Если ты рефакторишь класс тесты у тебя должны продолжить работать, если что.

Товарищи, а где в дс можно савина купить в переплете? Интернет магазины пусты :(

Или ты хреново рефакторишь.

окей, я подкорректирую свое изначальное утверждение. обложиться е2е так, чтобы они заменили юниты – долго и дорого

Если ты рефакторишь класс тесты у тебя должны продолжить работать, если что.

Рефакторинг может заключаться в разбитии класса на 5 других классов, что потребует написания совсем других тестов

окей, я подкорректирую свое изначальное утверждение. обложиться е2е так, чтобы они заменили юниты – долго и дорого

Это невозможно, они не заменяют друг друга в принципе.

Рефакторинг может заключаться в разбитии класса на 5 других классов, что потребует написания совсем других тестов

Да. И это правильно, это так и должно работать.

Shoo а ты лекции читаешь или может на конфах выступал ?

Shoo а ты лекции читаешь или может на конфах выступал ?

Мне не о чем особо рассказывать на конфах, я занимаюсь абсолютно примитивными штуками.

Лекции читаю, как видишь.

Это невозможно, они не заменяют друг друга в принципе.

ты можешь функциональные тесты написать так, что от них будет эффект как от юнитов, вопрос цены :)

:D

это йоба-недостижимое покрытие