ŹR
Я честно говоря тоже такие тесты пишу, но фактически смысл каждого теста что у тебя есть black box, и в случае acceptance test этим должно быть вся твоя система
Size: a a a
2018 November 01
FM
а так абстракция теста течёт, если щупать снаружи, а проверять внутренности. такие тесты тяжко поддерживать
ŹR
А в случае unit - blackbox это твой юнит
ŹR
Так то можно писать тест для генсервера - дернуть АПИ, а потом через рефлексию проверить его стейт
ŹR
Но это типа фуфло
FM
ну да, нельзя безболезненно сменить структуру стейта или вот поменять етс на редис (например)
FM
хотя внешнее поведение не меняется
АП
чтобы проверить функциональность отображения онлайн юзеров в чяте надо зайти из-под двух юзеров и проверить, что один видит другого как онлайн
1 тест - после авторизации пользователь становится онлайн
2 тест - пользователь добавляет другого пользователя в контакт лист, отношение сохранено в бд
3 тест - пользователь из контактов текущего выходит в онлайн, а первый видит его онлайн статус
2 тест - пользователь добавляет другого пользователя в контакт лист, отношение сохранено в бд
3 тест - пользователь из контактов текущего выходит в онлайн, а первый видит его онлайн статус
FM
когда мы тестируем как пользователь, нам плевать на бд
FM
как оно там внутри хранится
FM
пользователь твоей приложухи не заходит к тебе в етс, он только морду теребит
АП
пользователь твоей приложухи не заходит к тебе в етс, он только морду теребит
это не важно ваще никак. если результатом работы некого функционала интерфейса является изменение чего-то в базе данных, например - то и проверять надо изменение в базе данных. корректное отображение базы данных в интерфейсе могут проверять совсем другие сценарии. нет нужды многократно проверять одно и то же. тест должен проверять как можно более атомарные вещи.
если, к примеру, мы говорим об онлайн статусе пользователя - он может быть проверен десятком других сценариев.
если, к примеру, мы говорим об онлайн статусе пользователя - он может быть проверен десятком других сценариев.
FM
ну вот я не считаю хорошей практикой смешивать уровни абстракции, в том числе в тестах
FM
по твоей логике можно и состояние регистров в процессоре проверять – это более атомарно
АП
а по твоей логике дописать к тесту километр кода это здорово, можно себе галочку поставить, что не смешал уровень абстракций, а кто будет это разбирать потом - да пофиг
FM
у тебя же всё равно есть второй тест на то, что состояние из бд отображается юзеру на морде
FM
почему бы не объединить их в тест на одном уровне, что один юзер видит другого? так наоборот меньше кода будет
FM
и главное, потом меньше времени на поддержку потратишь, потому что они не поломаются при рефакторинге
АП
АП
потому что это потом превращяется вот в такое вот неподдерживаемое говно на несколько экранов