Комфорт — это как раз таки субъективное значение, которое свойственно UX в целом. Сайт с плохим usability вряд ли будет удобным во взаимодействии (одно из определений UX). Но сайт с хорошим usability не обязательно будет комфортен для посетителя.
В статье «Разница между Юзабилити и User Experience» приводится пример сайта Якоба Нильсена — у него хороший usability, но UX хромает.
Спасибо! Поправил. Если еще какие-то замечания или несоответствия по переводу, то пишите, пожалуйста, в личку или, есть время, можно править на сайте translated.by (я потов внесу изменения на этой странице.
Автоматическим переводчиком не пользуюсь — если где и коряво, то это мой русский или хвосты от множественного редактирования. Если можете дать свой перевод, и он будет хорош — то заменю им свой =)
Тут вы правы — с вебом дела посложнее. Можно, конечно, говорить, что в статье больше рассматривается работа собственной програмы (которую вы можете контролировать), а не стороннего браузера и мол это задача верстальщика, а не программиста. Но если считать верстальщика в каком-то роде программистом, то тут с вами не поспоришь. Если речь идет о Javascript, то существуют программы для тестирования, а вот для CSS хорошего решения нет.
P.S. Я задал вопрос автору по этому поводу. Если хотите пообщаться по этому поводу, то пишите ему в блог (он мне быстро ответил).
Согласен, что определение дано не совсем обычно, но время выполнения это основной признак модульных тестов — большинство тестов более высокого уровня выполняются дольше. Наложив ограничение на время выполнения, вы придете к пониманию того, какие вещи можно протестировать за это время и придете к выводу, что это модульные тесты в классическом их понимании (они и описаны в статье).
Зависит от того как написаны тесты — порой, для того, чтобы понять назначение теста, достаточно просто взглянуть на него — это называется самодокументированным кодом и комментарии бывают лишними.
Хотя не скрою, есть ситуации когда подобные комментарии могут быть полезны.
habrahabr.ru/blogs/testing/64874/
Перевел статью, которая даст дает объяснение понятию модульного теста и избавит от некоторых вопросов в комментариях.
Тут, скорее всего, ошибка в определении того, что считать unit-тестами. Есть статья того-же автора по поводу классификации тестов.
Так вот следуя этой классификации unit-тесты — это тесты, которые выполняются очень быстро и проверяют конструкции с условиями перехода (if...else, циклы), которые являются основными источниками багов в коде.
Функциональные и приемочные тесты, чаще всего, выполняются намного дольше и их не следует включать в набор тестов для фонового тестирования в IDE.
Никто не заставляет использовать данную технику — кто-то хочет быть уверен в программе каждые 10 секунд, кто-то не обращает на результаты фоновых тестов никакого внимания. В любой момент можно включить/выключить автоматическую прогонку тестов — это дело вкуса и культуры тестирования для каждого отдельно взятого человека.
В статье «Разница между Юзабилити и User Experience» приводится пример сайта Якоба Нильсена — у него хороший usability, но UX хромает.
P.S. Я задал вопрос автору по этому поводу. Если хотите пообщаться по этому поводу, то пишите ему в блог (он мне быстро ответил).
Хотя не скрою, есть ситуации когда подобные комментарии могут быть полезны.
Перевел статью, которая даст дает объяснение понятию модульного теста и избавит от некоторых вопросов в комментариях.
Так вот следуя этой классификации unit-тесты — это тесты, которые выполняются очень быстро и проверяют конструкции с условиями перехода (if...else, циклы), которые являются основными источниками багов в коде.
Функциональные и приемочные тесты, чаще всего, выполняются намного дольше и их не следует включать в набор тестов для фонового тестирования в IDE.