Логика фронтэнда поблочного тестирования [закрывается]
Как насчет ncrypt? Это не чистый Python, но это намного быстрее в результате. Это - в основном хорошая обертка Python на OpenSSL, таким образом, Вы знаете, что существует качественный код позади него.
4 ответа
Логика внешнего интерфейса модульного тестирования чрезвычайно сложна, поскольку существует множество составляющих ее частей, например, изменения кода на стороне сервера для внешнего интерфейса, а изменения на стороне клиента могут повлиять на внешний вид приложения.
В блоге Google по тестированию они говорили о ценности тестирования всех частей MVP и ценности тестирования AJAX путем включения дорогих частей сюда . Миско Хевери рассказывает о различных тестах здесь , и я чувствую, что тесты Front End попадают в его большую категорию тестов, поэтому всегда есть вероятность ложноотрицательных / положительных результатов, но их нужно отсортировать, потому что они по-прежнему предлагают много of value
Внешние тесты чрезвычайно важны, поскольку они проверяют, не снизилась ли функциональность пользователя. Вот почему такие инструменты, как Selenium и Watir , так популярны.
Исправить разбитое окно. вот ссылка на теорию http://en.wikipedia.org/wiki/Fixing_Broken_Windows
Успешная стратегия предотвращения низкого качества кода - это всегда поддерживать вашу базу кода в чистоте и в престижном состоянии. Это означает очистить весь плохой код. Это может быть болезненно и отнимать много времени, но вам все равно придется это делать.
После того, как мы удалили все предупреждения компиляции в нашем проекте, мы обнаружили, что качество нашего кода улучшилось. Люди начинают заботиться о том, что они проверяют, поскольку мы посылаем сигнал, что проверять неверный код - недопустимо (даже предупреждение - недопустимо), и никто не хочет быть первым, кто сломает окно.
Другая ловушка при тестировании пользовательского интерфейса заключается в том, что особенно легко написать тесты, которые тестируют структуру , а не ваше приложение. Или наоборот: может быть сложно написать тест, который на самом деле тестирует ваш UI, а не UI фреймворк .
Например, некоторые команды в конечном итоге пишут множество бесполезных тестов, таких как:
Given a button, when the button is clicked, the event handler should fire.
Вопрос для меня будет заключаться в выборе компромисса между затратами на поддержку тестов и вероятностью обнаружения ошибок, которые иначе не были бы обнаружены. Предположительно, у вас все еще будет визуальное тестирование реального пользовательского интерфейса (в противном случае вы действительно хорошо справитесь с тестированием эстетики).
Можете ли вы, например, сосредоточиться только на некоторых аспектах Presenter. Например, нетривиальное средство форматирования, поупражняйтесь в нем с множеством интересных значений.
Я подозреваю, что один из способов убедить - действовать медленно. Сначала попробуйте найти тесты, не требующие больших усилий.