Как Вы тестируете/изменяете непротестированный и непригодный для тестирования код?
Попробуйте поместить document.getElementById в setTimeout()
Например.
setTimeout(function(){
console.log(document.getElementById('whatever'));
}, 100);
Если это сработает, тогда это просто проблема синхронизации.
4 ответа
В первую очередь, вот большая статья с подсказками относительно поблочного тестирования. Во-вторых, я нашел, что отличный способ постараться не делать тонны изменений в старом коде состоит в том, чтобы просто осуществить рефакторинг его немного, пока Вы не можете протестировать его. Один простой способ сделать это должно сделать членов парламента, не занимающих официального поста защищенными и затем переопределить защищенное поле.
Например, скажем, у Вас есть класс, который загружает некоторый материал из базы данных во время конструктора. В этом случае Вы не можете только переопределить защищенный метод, но можно извлечь логику DB к защищенному полю и затем переопределить ее в тесте.
public class MyClass {
public MyClass() {
// undesirable DB logic
}
}
становится
public class MyClass {
public MyClass() {
loadFromDB();
}
protected void loadFromDB() {
// undesirable DB logic
}
}
и затем Ваш тест выглядит примерно так:
public class MyClassTest {
public void testSomething() {
MyClass myClass = new MyClassWrapper();
// test it
}
private static class MyClassWrapper extends MyClass {
@Override
protected void loadFromDB() {
// some mock logic
}
}
}
Это - своего рода плохой пример, потому что Вы могли использовать DBUnit в этом случае, но я на самом деле сделал это в подобном случае недавно, потому что я хотел протестировать некоторую функциональность, полностью не связанную с загружаемыми данными, таким образом, это было очень эффективно. Я также нашел, что такое представление участников полезно в других подобных случаях, где я должен избавиться от некоторой зависимости, которая была в классе в течение долгого времени.
Я рекомендовал бы против этого решения, если Вы пишете платформу, хотя, если Вы действительно не возражаете подвергать участников пользователям Вашей платформы.
Это - определенный взлом, но я нашел это довольно полезным.
@valters
Я не соглашаюсь с Вашим оператором, который тесты не должны повреждать сборку. Тесты должны быть признаком, что приложению не представили новые ошибки для функциональности, которая тестируется (и найденная ошибка является признаком недостающего теста).
Если тесты не повреждают сборку, то можно легко столкнуться с ситуацией, где новый код повреждает сборку, и это не известно некоторое время, даже при том, что тест покрыл его. Провальный тест должен быть красным флагом, что или тест или код должны быть зафиксированы.
Кроме того, разрешение тестов не повредить сборку заставит интенсивность отказов медленно накапливаться, до такой степени, когда у Вас больше нет надежного набора регрессионных тестов.
Если существует проблема с тестами, повреждающимися слишком часто, это может быть признак, что тесты пишутся слишком хрупким способом (зависимость от ресурсов, которые могли измениться, такие как база данных, не используя Единицу DB правильно или внешний веб-сервис, который нужно дразнить), или это может быть признак, что существуют разработчики в командах, которые не уделяют тестам надлежащее внимание.
Я твердо полагаю, что провальный тест должен быть зафиксирован как можно скорее, как Вы исправили бы код, которому не удается скомпилировать ASAP.
Я не уверен, почему Вы сказали бы, что модульные тесты идут быть удаленными, после того как рефакторинг завершается. На самом деле Ваш комплект модульного теста должен бежать за основной сборкой (можно создать отдельную "тестовую" сборку, которая просто выполняет модульные тесты после того, как основной продукт создается). Затем Вы будете сразу видеть, повреждают ли изменения в одной части тесты в другой подсистеме. Обратите внимание, что это несколько отличается, чем запущение тестов во время сборки (поскольку некоторые могут защитить) - некоторое ограниченное тестирование полезно во время сборки, но обычно это непроизводительно для "разрушения" сборки просто, потому что некоторый модульный тест, оказывается, перестал работать.
Если Вы пишете Java (возможности), проверьте http://www.easymock.org/ - может быть полезно для сокращения связи в тестовых целях.
Я считал Работу Эффективно С Унаследованным кодом, и я соглашаюсь, что это очень полезно для контакта с "непригодным для тестирования" кодом.
Некоторые методы только относятся к скомпилированным языкам (я работаю над "старыми" приложениями PHP), но я сказал бы, что большая часть книги применима к любому языку.
Осуществляющие рефакторинг книги иногда предполагают, что код находится в полуидеале или "обслуживании осведомленное" состояние перед рефакторингом, но системы, я продолжаю работать, являются меньше, чем идеал и были разработаны, как "узнают, поскольку Вы идете" приложения, или как первые приложения для некоторых используемых технологий (и я не обвиняю начальных разработчиков в этом, так как я - один из них), таким образом, нет никаких тестов вообще, и код иногда грязен. Эта книга обращается к этому виду ситуации, тогда как другие книги рефакторинга обычно не делают (хорошо, не до этой степени).
Я должен упомянуть, что не получил денег от редактора, ни автора этой книги ;), но я нашел это очень интересным, так как ресурсам недостает в области унаследованного кода (и особенно на моем языке, французском языке, но это - другая история).