вопрос по идеологии так как раньше не пользовался.

допустим есть класс в котором дюжина методов.
один из методов - логин в админку дашборда.
внутри себя он делает три вещи
1. переход по урл
2. заполнение login/pass + сабмит
3. проверка что на странице появился нужный элемент

метод возвращает boolean

дальше берем TestNG и рисуем методу тест:

public class MyTest {

private adminRobot robot = new adminRobot();

 @Test
 public void checkLogin() {
  Assert.assertEquals(true, robot.Login(user_name, user_pass));
 }

сам вопрос:
мне чего-то кажется, что простое сравнение на true (Assert.assertEquals(...)) хоть и покажет что тест пройден, но не гарантирует что логон был действительно успешен

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

или наоборот.
поля заполнили неверно, или сабмит сделан криво, но поиск "проверочного" элемента может возвратить true (потому что там ошибка)

как там по фэншую-то делается?

Ошероув Р. «Искусство автономного тестирования с примерами на C#» ДМК Пресс, 2014 год,
Пишет, что это по феншую.

А вот то что вы хотите проверяется Фазингом. Но он плохо автоматизируется.

> например поля заполнились верно, сабмит ушел красивый, а
> дальше элемент ищется неверно и получаем false
>
> или наоборот.
> поля заполнили неверно, или сабмит сделан криво, но поиск
> "проверочного" элемента может возвратить true (потому что
> там ошибка)

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

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

Вот эта гифка юмористическая, но она вполне передает саму суть юнит-тестирования и отличия юнит-тестов от интеграционных тестов.

https://michelenasti.com/images/unit-testing-1.gif

Сегодня добрался до 100 странице. Разрываем внешнюю зависимость. Путём создания интерфейса подобному внешнему API. Проводим рефакторинг. И через подстановку использу объект инверсии вводим в тестируемый класс параметры.

Всё очень просто.

> Писать легко тестируемый код - это блин целая наука.

Не представляю как это вообще возможно сделать на чем-то большом и быстроразвивающимся.