Pinkbyte, пни пацанов, please.

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

Бесплатные мейнтейнеры обычно поддерживают софт, который им нужен, поэтому обычно таки руками проще.

И как вы проверите сложную гуёвую программу?

если приходится проверять на куче профилей + все комбинации юзфлагов то не проще.

И как вы проверите сложную гуёвую программу?

Все то же самое что и руками. Клавиатура и мышка имитируются, после выполнения теста делается скриншот и сравнивается с эталонным скриншотом.

В вебе куча фреимворков для тестирования интерфейсов сайтов, все уже придумали.

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

Это всё очень хорошо звучит в теории, но когда поддерживаешь в одно рыло 500+ пакетов(я до такого не доходил, но коллег-разработчиков упарывающихся настолько - знаю) в туче вариации USE-флагов - это не работает.

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

https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

вот это самый простой способ прикоснуться к миру поддержки ебилдов?

Приходи к нам в Fedora CI расскажешь как всё просто :)

Кстати сказать интеграционные тесты которые RH постепенно апстримит в федору вполне можно попробовать применять в генте. Но конечно допиливать придётся немало.

Да. Pull request-ы можно слать через GitHub.

если приходится проверять на куче профилей + все комбинации юзфлагов то не проще.

Сборка автоматизируется. Не думаю, что прямо всё тут руками проверяется.

В вебе куча фреимворков для тестирования интерфейсов сайтов, все уже придумали.

Это в вебе, тут технологии постарее.

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

В sandbox?

Для таких задач в крупных конторах QA команды спец софт используют и написание подобных тестов (по всем пунктам менюшек и фич?) пробежаться не так быстро ощуществляется.

Можешь начать с guru, там требования послабее к QA. Сейчас новые пакеты в генту через proxy-maint очень востребованные новые пакеты принимают.

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

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

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

Системные тесты - это да, они гоняются, но для gui в полной мере их нет нигде, а там где есть, их не так много.

Я про тесты, которые именно gui гоняют активно, в том числе на предмет результата этих действий.

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

Открою страшную тайну: я собираю и тестирую для одного профиля, одной архитектуры ;)

Да, иногда это не позволяет найти некоторые баги сборки.

Обновляешь циферки в ебилде, если все работает, закидываешь пулл-реквест на их жидхаб, он проходит ревью и вуаля - пакет в основном дереве обновлен.

Бери https://github.com/nodenv/nodenv и устанавливай любую версию nodejs даже без СМС прав рута.

Но есть утилита, для проверки сборки для нескольких настроек и формирования отчёта.

Добавленные ebuild’ы потом в tinderbox собираются, в чистом профиле.

https://xkcd.com/292

Я вот всё жду, когда ко мне динозавр прибежит. А он всё не бежит и не бежит…

в мире ноды обновления раз в пару недель - это нормально

Уже давно есть lst нода, да и всякого легаси, которое не обновляется полно. Дед, ты всё проспал, нода - это уже нормальный ынтерпрайз, как эта твоя жабка.

Я сижу на current за исключением, когда авторы фреймворка - деды и не смогли ничего кроме LTS.

Пока что у меня всего один пример этого: Electron + Angular + Puppeteer в одной кодовой базе. Робот, автоматизирующий клики по веб-интерфейсам, с гуём на Электроне. Там постоянно что-то у них разъезжается между собой, и на LTS чинить надо меньше.

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

как по твоему тестируют интерфейсы сайтов?

Я сижу на current за исключением, когда авторы фреймворка - деды и не смогли ничего кроме LTS.

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

Тебе в реальности рассказать или в теории? В реальности в Москве ещё 2 года назад нанимали студентов за еду (точно знаю, т.к. у меня родственница как раз училась на айти и работала кнопкотыком на тестировании пока училась) и по её словам, студенты занимались кнопкотыканьем, иногда с привлечением некоторого софта для автоматической записи действий. Но вот проблема - добавили кнопку/изменили размер полей ввода/подвинули их чуть-чуть и всё, приплыли. А порой и весь дизайн перетряхают. Ещё в теории можно тесты писать которые к элементу управления напрямую программно будут обращаться, в зависимости от технологии, но там тоже не всё так гладко как хочется.

А в теории - умные и клёвые системы автоматического тестирования да ещё с ИИ на борту должны всё сами делать. Вот только их нету или стоят они соизмеримо с МКС.

А что делать когда написаны функциональные или юнит тесты, а функционал поменялся?

:) по умному, перепиливать под новые условия.
по практике, подоткнуть костылями, чтобы побыстрее тесты начали обрабатываться

ну вот нету никакой разницы будет в тесте логический экспектейшен или в виде картинки.