Состоялся митинг по автоматизации. После него ощущаю беспокойство, пока неясное. Это означает, что его результаты меня не удовлетворяют. Попробую разобраться, что именно мне не нравится.
1. Тестирование дизайна. Имеется ввиду попиксельное сравнивание изображений - полученноо во время тестирования и эталонного. Пока что мы это импользовать не будем.
2. Сообщение о баге сопровождается Selenium-тестом. Сережа предложил. Идея, конечно, интересная. Можно попробовать. Но здесь есть вопросы, в каком именно виде этот тест должен быть представлен. Разработчик должен иметь возможность легко этот тест запустить и ясно увидеть, что именно работает не так.
3. Участвовать в форумах. Опять же, Серёжа упомянул эту возможность. Если есть проблема, ею можно поделиться с сообществом. Посмотрим...
4. Документация. Пока что у нас наблюдается пренебрежительное к ней отношение. На ней смотрят, как на какую-то ненужную обузу. У меня же другой взгляд. Документ - это в первую очередь источник идей для тестов. Чтобы что-то автоматизировать, нужно знать, что именно автоматизировать. Тесты, придуманные без анализа, не могут претендовать на полноту того же покрытия функциональности. А если проводится анализ, то документы рождаются сами собой: диаграммы, схемы, спецификации, просто заметки. Почему бы всё это не сохранять и не использовать в последующем? Я уж не говорю, что всё это должно быть готово ещё перед реализацией функциональности, а не перед её тестированием. Лично я буду продолжать создавать документы.
5. Было принято решение размещать тесты в классах, соответствующих каким-либо частям функциональности. Сначала я был против, потому что в этом случае будет происходить смешение ролей пользователей, так как очень часто функциональностью это поразумевается. А потом в разговоре с Лёнькой пришли к выводу, что это требование, в принципе, не помешает моему представлению о том, какими должны быть тесты, потому что каждый отдельный тест, в принципе, есть тест какой-то функциональности, единичной функциональности, так что каждый тест и так уже соответствует этому требованию.
6. Логирование. Использовать Selenium Logging. Эту возможность я уже реализовывал на отдельном примере, но подробно не рассматривал. Её применения нельзя назвать простым, довольно капризная штука. А вот сколько от неё будет пользы... ещё вопрос. Может быть, удобнее использовать своё собственный лог. А картинки, если в них есть необходимость, Selenium умеет делать сам. В общем, тут ещё нужны исследования.
7. Андрей Круглянко подключается ко мне в смысле написания тестов для Common Agenda. Это проблема. Как мы можем писать что-то вместе, если у меня у самого ещё не сформировалась концепция того, как это должно делаться. А если и сформируется, то совсем не факт, что Андрей захочет её поддерживать. Он привык писать тесты по-старому. Мне такой подход не нравится, а новый я ему предложить пока не могу. В общем, пока он займётся восстановлением тех тестов для Common Agenda, которые висят в проекте и которые он же и спроектировал. Если они заработают, то послужат образцом старого стиля.
8. Названия методов-тестов. test_<функциональность>_<функциональность>_...(). В общем, что-то типа такого: test_Widget_CategoriesList_Visibility().
9. Нужно почитать про метод Selenium assignedID(). Это для борьбы с длинными путями XPath. Нужно выяснить, чем это лучше обычного назначения новой переменной с коротким именем.
10. Автозапуск тестов. С Женькой нужно обеспечить ночной запуск тестов по расписанию. Для этого нужно разобраться, что именно необходимо сделать мне с кодом, чтобы это всё работало.

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