Unit Test. Кто использует?
Слой оттестирован - все методы работают как ожидается.А вот все остальное - не работает.
В такой ситуации, когда внесли изменения в "слой", а поехало "все остальное", мне приходит в голову только вариант, что "слой" используется каким-то способом, который не покрыт тестами.
То есть, вот это утверждение "все методы работают как ожидается" не совсем верно. Как вариант, может быть, играет роль последовательность вызовов методов "слоя", которая раньше давала один результат, а после внесения изменений стала выдавать другой.
Забыл унаследовать :) Писал на коленке :) Но идея, думаю, понятна ;)
Это - не проблема: юнит тест мигом бы выявил : )
В Вашем конкретном коде он бы ничего не выявил, т.к. классы нигде не используются. А просто иметь в независимых классах методы с одинаковыми именами - в порядке вещей. Попробуйте откомпилировать, Вам проще - Вы ведь под "коленом" не окошко ввода этого форума имели ввиду? Т.е. если и заругается компилятор, то не по поводу упущенного наследования.
Пробовать не буду :) Тебе придраться или как? Мысль заключалась в том, что некая функция используется дофига раз, а тестировать эту функцию смысла нет. Тестировать надо то, что, в данном случае, вообще ни разу не используется на прямую.
PS: добавил наслодование от интерфейса. вроде туда :D
Да это ясно: тестировать нужно только то, что имеет смысл тестировать.
Код зря корректировали: все равно никто не будет использовать : )
Мысль заключалась в том, что некая функция используется дофига раз, а тестировать эту функцию смысла нет
Я бы взял аналогию с автомобилями - светофор раньше всего нужно ставить там, где они дофига ездят. А ставить его на выезде в поле, на окраине большого смысла нет.
"Вычислить" где делать, а где нет думаю не получиться. А вот знать где наиболее "важные" места в программе вполне можно.
А кто сказал, что "тдд" и "интересно" обязательно идут нога в ногу? Мне вот иногда интересно какой-нить гейзенбаг найти :))
На любой работе есть скучная рутина. Вопрос в том, чего больше. Ну и когда наступит момент пресыщения, после которого на работу не хочется ни за какие ковришки :)
У меня сейчас как раз такой момент :) Ухожу :D
Вообще-то, Я поленился отквотить исходник в надежде что все и так будет понятно. Ну да ладно - вот "исходный постулат":
То есть, если в приложении есть какие-то слой "универсальных" сущностей, например, какой-нибудь модуль доступа к данным, то он должен быть хорошенько покрыт Unit-тестами.
Я привел тебе пример, когда 100% покрытие тестами этого "универсального" слоя не дает никакого полезного результата.
Тут же ты сам и говоришь:
приходит в голову только вариант, что "слой" используется каким-то способом, который не покрыт тестами.
Разумеется. Но 100% тест этого слоя этого факта не выявляет. Просто потому что это другой код.
может быть, играет роль
Там изменена методика передачи параметров, а плугины об этом пока не знают. Что и как исправлять - понятно, но тесты "универсального" уровня этого выявить не могут.
Не знаю еще :) Пока что я только сообщил шефу, что ухожу :) Пового проекта еще нет :D
А применим ли юнит тест в мультипоточной среде? Как можно протестировать "юнит", если результат зависит от того, что происходит в других потоках?
но тесты "универсального" уровня этого выявить не могут.
Это мы просто тута только об одном уровне говорили.
В одном проекте было типа: внутри модульные, модульные и межмодульные.
Но в любом случае тесты не дают полной гарантии рабоспособности программы. Это всего лишь еще один дополнительный инструмент.
а какие у вас требования и какие умения?
http://foren.germany.ru/arch/jobs/f/30833621.html?Cat=&pag...
для фриланса естественно другая оплата.
Жуть :)