Это очень интересная (лично для меня) тема и она достойна отдельной статьи. Как только я найду чуть больше времени я обязательно напишу про асинхронное Ajax тестирвоание
Эта часть тестов является проектированием через тестирование.
Код непосредственного тестирования результатов находится после проектирования. Ведь логично сперва разработать структуру, а лишь затем — реализацию. Об этом я как раз и писал.
По поводу полезности от куч багов — дальнейшие проверки проверяют как раз корректность выполнения методов.
Я не стал перегружать излишними проверками, т.к. лишь показал общий принцип. В реальном объекте тесты проектирования занимают менее 10%
Баг в ИЕ9 был скорее не багом — на 10 пикселей ниже чем нужны было завершение окна. И даже если бы QA не нашли — приложение работало бы корректно, скорее всего пользователи не узнали бы о том, что баг существует. Ну разве что сравнили с другим браузером.
Я же писал — проектирование при помощи TDD. Все дело привычки и личных предпочтений — на практике для моего проекта методология TDD показала потрясающие результаты.
Если приложение ориентированно на контент, который можно «почитать с большого экрана на диване», то для корректного отображения на больших экранах можно использовать шрифт в em.
«В конце концов мы решили использовать png24 с полупрозрачными краями накладывающиеся друг на друга»
Код непосредственного тестирования результатов находится после проектирования. Ведь логично сперва разработать структуру, а лишь затем — реализацию. Об этом я как раз и писал.
По поводу полезности от куч багов — дальнейшие проверки проверяют как раз корректность выполнения методов.
Я не стал перегружать излишними проверками, т.к. лишь показал общий принцип. В реальном объекте тесты проектирования занимают менее 10%
Я же писал — проектирование при помощи TDD. Все дело привычки и личных предпочтений — на практике для моего проекта методология TDD показала потрясающие результаты.