А вы не пробывали в большей степени смотреть в сторону юнит-тестирования, а не функционального? В любом случае пиксел-зависимые тесты достаточно трудно поддерживать при изменяющихся условиях. Сравнение с эталонными картинками и чек-суммами будет приводить к необходимости постоянно их обновлять. Лучшие тесты, это те, которые будут работать не зависимо от изменяющихся условий.
Привязка к значениям координат окна в таких тестах не есть хорошее решение. Для такого способа критичны будут изменения разрешения экрана (напр. переход в 120 DPI) или размеров шрифтов, элементов управления (к примеру ширины полос прокрутки и т.д). Интересно, как с этим справляется AutoIt3?
Если же тестирование всегда производится в неизменяемой среде, то другое дело…
Опять же изменение GUI программы (напр. скины) обяжет вас писать другие наборы тест-кейсов для всех случаев.
Перед коммитом запускаются те, которые не имеют тагов типа «integration»
Существует ситуация когда должен быть заложен код, в результате которых перестают работать тесты. Как я понимаю, вы правите тесты, помечаете их тэгом Integration и закладываете совместно с кодом. Как налажен процесс того, кто потом очистит тэги, что бы тесты не пропускались перед последующими закладками?
В заголовке файлов есть поля, которые парсятся при коммите.
А пробывали? По опыту себя и коллег, простая смена клавы на эргономику резко меняет стиль печати на более «правильный» и впоследствии более скоростной. В случае, если не прилагать усилий и не практиковаться постоянно, то и смена раскадки не поможет.
Кстати, никогда бы не подумал изучая GPSS, что может когда-то пригодится… Позднее автоматизировали производственный процесс и встала задача моделирования технологического пути прохождения деталей по станкам. Система обслуживающих аппаратов, транзакций и очередей «один в один» как в GPSS. Правда реализовали все это на Delphi, но работало на «ура».
У нас в ТулГУ в приложении к курсу «Экспертные Системы» тоже учили Prolog и даже лабы делали. А вот где реально мозг перестраивать надо — так это GPSS ;)
А не пробывали просто перейти на эргономичную клавиатуру — к примеру, на Microsoft Natural Ergonomic Keyboard 4000?
Так как в ней клавиши разнесены по сторонам — так что естественным образом не удобно печатать левой рукой на правой стороне и наоборот. Как результат — руки станут лежать там где надо )
>Поэтому руки перемещались на значительные расстояния над клавиатурой, поэтому при возвращении рук в исходное положение часто >пальцы оказывались не над теми клавишами.
Если же тестирование всегда производится в неизменяемой среде, то другое дело…
Опять же изменение GUI программы (напр. скины) обяжет вас писать другие наборы тест-кейсов для всех случаев.
Существует ситуация когда должен быть заложен код, в результате которых перестают работать тесты. Как я понимаю, вы правите тесты, помечаете их тэгом Integration и закладываете совместно с кодом. Как налажен процесс того, кто потом очистит тэги, что бы тесты не пропускались перед последующими закладками?
О каких файлах идет речь?
А можно поинтересоваться насчет времени прохождения тестов перед закладкой?
Как осуществляется выбор того, кто должен проводить ревью кода?
Так как в ней клавиши разнесены по сторонам — так что естественным образом не удобно печатать левой рукой на правой стороне и наоборот. Как результат — руки станут лежать там где надо )
>Поэтому руки перемещались на значительные расстояния над клавиатурой, поэтому при возвращении рук в исходное положение часто >пальцы оказывались не над теми клавишами.