Инструкции по поблочному тестированию
Настройка scrollTop делает это (вы устанавливаете его на documentElement в большинстве браузеров, но на body на других, проще всего просто установить его на обоих). Кроме того, это число (нет px).
Но вы должны сделать это в нужное время, которое после перезагрузки страницы, возможно, после setTimeout или даже в onload (вам нужно поэкспериментировать, чтобы выяснить, что работает на вашей странице). Вот пример setTimeout:
setTimeout(function() {
document.documentElement.scrollTop =
document.body.scrollTop = 500;
}, 0);
Однако я бы этого не сделал. Вместо этого я передам значение флажка через ajax и не перезагружаю страницу. Даже если вы прокрутите страницу вниз до того места, где был пользователь после перезагрузки, все равно сюрприз для перезагрузки страницы, когда вы устанавливаете флажок (я помню, что Amazon использовал для этого), и это требует времени. Ajax разрешил бы это происходить в фоновом режиме, не прерывая пользователя.
7 ответов
Я рекомендовал бы Kent Beck книга по TDD.
кроме того, необходимо перейти в Martin Fowler сайт. У него есть большая хорошая информация о тестировании также.
Мы довольно хорошо разбираемся в TDD, таким образом, я отвечу на вопросы в том свете.
Должен тесты быть в том же проекте как прикладная логика?
Обычно мы сохраняем наши тесты в том же решении, но мы повреждаем тесты в отдельный DLL/проекты, которые зеркально отражают DLL/проекты, который они тестируют, но поддерживают пространства имен с тестами, находящимися в sub пространстве имен. Пример: Распространенный / Распространенный. Тесты
у меня должны быть тестовые классы для зеркального отражения моих логических классов, или у меня должно быть только столько тестовых классов, сколько я чувствую, что должен иметь?
Да, Ваши тесты должны быть созданы, прежде чем любые классы создаются, и по определению необходимо только протестировать единый блок в изоляции. Поэтому у Вас должен быть тестовый класс для каждого класса в Вашем решении.
, Как должен, я называю свои тестовые классы, методы и проекты (если они входят в различные проекты)
, мне нравится подчеркивать, что поведение - то, что тестируется так, я обычно называю тестовые классы в честь SUT. Например, если бы у меня был Пользовательский класс, то я назвал бы тестовый класс как так:
public class UserBehavior
Методы нужно назвать для описания поведения, которое Вы ожидаете.
public void ShouldBeAbleToSetUserFirstName()
Проекты можно назвать однако, Вы хотите, но обычно Вы хотите, чтобы он был довольно очевиден, какой проект это тестирует. См. предыдущий ответ об организации проекта.
Должен частные, защищенные, и внутренние методы быть протестированным, или просто те, которые публично доступны?
Снова Вы хотите, чтобы тесты утверждали ожидаемое поведение, как будто Вы были сторонним потребителем протестированных объектов. При тестировании внутренних деталей реализации тогда тесты будут хрупкими. Вы хотите, чтобы Ваш тест дал Вам свободу осуществить рефакторинг, не волнуясь о повреждении существующей функциональности. Если Ваш тест знает о деталях реализации тогда необходимо будет изменить тесты, если те детали изменяются.
модульные и интеграционные тесты должны быть разделены?
Да, модульные тесты должны быть изолированы от приемочных испытаний и интеграционных тестов. Разделение проблем относится к тестам также.
там серьезное основание не иметь 100%-е тестовое покрытие?
я не добрался бы до одержимого 100%-й вещью покрытия кода. 100%-е покрытие кода имеет тенденцию подразумевать некоторый уровень качества в тестах, но это - миф. Вы можете иметь ужасные тесты и все еще получить 100%-е покрытие. Я вместо этого полагался бы на хороший Тест Первый менталитет. Если Вы всегда будете писать тест перед записью строки кода тогда, то Вы гарантируете 100%-е покрытие, таким образом, это станет спорным вопросом.
В целом, если Вы фокусируетесь на описании полного поведенческого объема класса тогда, у Вас не будет ничего для волнения о. Если Вы сделаете покрытие кода метрикой тогда, то ленивые программисты просто сделают как раз достаточно для встречи той метки, и у Вас все еще будут дрянные тесты. Вместо этого положитесь в большой степени на экспертные оценки, где тесты рассматриваются также.
Это - хороший вопрос. Мы вырастили наше собственное органически, и я подозреваю, что лучший способ - просто это. Существует немного, "Это зависит..." там.
Мы производим тесты в том же проекте в подпространстве имен, названном "UnitTes"
, Наши тестовые классы зеркально отражают логический класс для упрощения отслеживания того, где тесты относительно того, что они тестируют
, Классы называют как логический класс, который они тестируют, методы названы по имени сценария, который они тестируют.
Мы только тесты записи на общедоступные и внутренние методы (тест находятся в том же проекте), и стремятся к 95%-му покрытию класса.
я предпочитаю не различать "единицу" и "intergation". К большому количеству времени будет потрачен, пытаясь выяснить, который является который... сумка это! Тест является тестом.
100% является слишком трудным для достижения все время. Мы стремимся к 95%. Существует также убывающая доходность на том, сколько времени потребуется для получения тех заключительных 5% и что это на самом деле поймает.
Это - мы и что удовлетворило среде и темпу. Вы - milage, может варьироваться. Думайте о своем envivonment nad личности, которые вовлечены.
я жду встречи с тем, что другие должны сказать относительно этого!
Ответ Josh's является правильным на - всего одна точка разъяснения:
причина я разделяю модульные тесты от интеграционных тестов, и приемочные испытания скорость. Я использую TDD. Мне нужно близко к мгновенной обратной связи о строке кода, который я просто создал/изменил. Я не могу получить это, если я выполняю полные комплекты интеграционных тестов и/или приемочных испытаний - тесты, которые поражают реальные диски, реальные сети, и действительно замедляются и непредсказуемые внешние системы.
не пересекают лучи. Плохие вещи произойдут, если Вы сделаете.
Я настойчиво рекомендую Вам читать Разработка через тестирование: Примером и Разработка через тестирование: Практическое Руководство Это - слишком много вопросы для единственной темы
Относительно Вашего последнего вопроса, по моему опыту, "хорошая" причина того, чтобы не настоять на 100%-м тестовом покрытии состоит в том, что это берет непропорциональное усилие для получения последних нескольких процентных пунктов, особенно в больших кодовых базах. По сути, это - вопрос решения, стоит ли это Вашего времени, как только Вы достигаете той точки убывающей доходности.
В порядке:
- нет, обычно лучше включать их в отдельный проект; если Вы не хотите быть в состоянии к запуску диагностики во времени выполнения.
- идеал является 100%-м покрытием кода, что означает каждую строку кода в каждой стандартной программе в каждом классе.
- я иду с ClassnameTest, ClassnameTest. MethodNameTestnumber
- Все.
- я сказал бы да, поскольку интеграционные тесты не должны быть выполнены, если модульные тесты перестали работать.
- свойства Simple, которые просто устанавливают и получают поле, не должны быть протестированы.
Должен тесты быть в том же проекте как прикладная логика?
Это зависит. Так или иначе существуют компромиссы.
Хранение это в одном проекте требует, чтобы дополнительная пропускная способность распределила Ваш проект, дополнительное время изготовления, и увеличивает место установки и облегчает делать ошибку наличия производственной логики, которая зависит от тестового кода.
, С другой стороны, разделяя проекты может сделать его тяжелее к тестам записи, включающим частные методы/классы (в зависимости от языка программирования), и вызывает незначительные стычки администрирования, такие как установка настройки среда новой разработки (например, когда новый разработчик присоединяется к проекту), тяжелее.
, Насколько эти различные затраты вопрос варьируются проектом, таким образом, нет никакого универсального ответа.
у меня должны быть тестовые классы для зеркального отражения моих логических классов, или у меня должно быть только столько тестовых классов, сколько я чувствую, что должен иметь?
№
у Вас должны быть тестовые классы, которые допускают хорошо учтенный тестовый код (т.е. минимальное дублирование, очистите намерение, и т.д.).
очевидное преимущество прямого зеркального отражения логических классов в Ваших тестовых классах состоит в том, что оно облегчает находить тесты, соответствующие конкретной части кода. Существуют другие пути, решают эту проблему, не ограничивая гибкость тестового кода. Простые соглашения о присвоении имен для тестовых модулей и классов обычно достаточно.
, Как должен, я называю свои тестовые классы, методы и проекты (если они входят в различные проекты)
, необходимо назвать их так, чтобы:
- каждый тестовый метод класса и метод тестирования имеют ясную цель, и
- так, чтобы кто-то ищущий конкретный тест (или для тестов о конкретной единице) мог найти его легко.
Должен частные, защищенные, и внутренние методы быть протестированным, или просто те, которые публично доступны?
Часто непубличные методы должны быть протестированы. Это зависит от того, если Вы получаете достаточно уверенности от просто тестирования открытого интерфейса, или если единица, которую Вы действительно хотите протестировать, не публично доступна.
модульные и интеграционные тесты должны быть разделены?
Это зависит от Вашего выбора среды (сред) тестирования. Сделайте, какой бы ни работы лучше всего с Вашей средой (средами) тестирования и делают его так, чтобы:
- и модульные и интеграционные тесты, касающиеся части кода, легко найти,
- легко выполнить просто модульные тесты,
- легко выполнить просто интеграционные тесты,
- легко запустить все тесты.
там серьезное основание не иметь 100%-е тестовое покрытие?
Да, существует серьезное основание. Строго говоря тест % “100 coverage” означает, что каждая возможная ситуация в Вашем коде осуществлена и протестирована. Это просто непрактично почти для любого проекта достигнуть.
при простом взятии “100 теста % coverage”, чтобы означать, что каждая строка исходного кода осуществлена набором тестов в какой-то момент, тогда это - хорошая цель, но иногда существует только несколько строк в неловких местах, которые труднодоступны с автоматизированными тестами. Если стоимость ручной проверки, что функциональность периодически является меньше, чем стоимость прохождения через искривлений для достижения тех последних пяти строк, то это - серьезное основание не иметь 100%-е покрытие строки.
, А не простое правило, что у Вас должно быть 100%-е покрытие строки, поощрите своих разработчиков обнаруживать любой разрывы в Вашем тестировании и находить способы зафиксировать те разрывы, улучшается ли или количество строк “covered”. Другими словами, при измерении покрытых строк тогда Вы улучшите свою строку coverge —, но что Вы на самом деле хотите, улучшенное качество. Не забывайте, что покрытие строки является просто очень грубым приближением качества.