Поблочное тестирование в CakePHP? [закрытый]
Различные спецификации W3C определяют различные наборы типов "Узла".
Таким образом, спецификация DOM определяет следующие типы узлов:
-
Document-Element(максимум одного),ProcessingInstruction,Comment,DocumentType -
DocumentFragment-Element,ProcessingInstruction,Comment,Text,CDATASection,EntityReference -
DocumentType- никаких детей -
EntityReference-Element,ProcessingInstruction,Comment,Text,CDATASection,EntityReference -
Element-Element,Text,Comment,ProcessingInstruction,CDATASection,EntityReference -
Attr-Text,EntityReference -
ProcessingInstruction- никаких детей -
Comment- никаких детей -
Text- никаких детей -
CDATASection- никаких детей -
Entity-Element,ProcessingInstruction,Comment,Text,CDATASection,EntityReference -
Notation- никакие дети
Инфонабор XML (используемый XPath) имеет меньший набор узлов:
XPath имеет следующие Типы узлов:
- корневые узлы
- узлы элемента
- текстовые узлы
- узлы атрибута
- узлы пространства имен
- узлы инструкции по обработке
- узлы комментария
ответ на Ваш вопрос ", Что является различием между элементом и узлом ":
An element is a type of node. Many other types of nodes exist and serve different purposes.
2 ответа
Мне интересно, как вы, ребята юнит-тест в CakePHP? Как ты включать тесты в проекты?
Я обычно использую самую простую настройку, используемую Cake Core. Я создал тестовый файл для каждого контроллера и модели. Я обычно тестирую вывод помощников / компонентов / поведения, если код имеет сложные параметры или помощник имеет в значительной степени переменный вывод. Я считаю, что мой охват составляет около 65-75%, и что даже при такой низкой степени покрытия кода моими тестами (65% ограниченного подмножества файлов довольно слабое) я обнаруживаю или исправляю с помощью тестов больше ошибок, чем обнаружил, и исправлено правильно без.
Что части проекта вы тестируете? Как вы решаете, какие части должны быть unit-tested?
I always test all Model functions. Custom find's, paginated result sets etc. I test them for the following. Correct number of results ( from a find on fixture data ), correct resultsets ( from a find on fixture data ), correctness of the fields returned, number of results returned and a correct dataset for each custom find type. Correct pagination if I am using paginated sets on any finds, custom or otherwise.
I always test controller functions that don't result in a view being rendered. As a habit I tend to move all logic that isn't dedicated to settings view vars or choosing a view to render to private / protected functions in the controller or to model function calls. Это позволяет мне напрямую тестировать оставшиеся действия контроллера (те, которые имеют вывод представления). Если я визуализирую представление вообще , то эти функции, вероятно, будут вести себя нормально с любыми проблемами с то, что визуализируется в дальнейшем по стеку вызовов.
Я тестирую помощники для их вывода с помощью набор определенных опций. Я не всегда охватываю все перестановки в массиве параметров, но когда два разных ключа приводят к взаимоисключающему поведению или я могу проверить, включены ли в мою разметку атрибуты predicatble в результате - я проверяю эти сценарии.
Если компонент берет данные откуда-то и манипулирует ими. Я также проверяю формат или возвращаю данные по функциям компонентов. То же самое и с поведением.
Если у меня где-то используется статический класс, я протестирую функции этого класса на предмет правильных возвращаемых результатов, а также на создание некоторых принудительных отказов или условий преднамеренной ошибки. В частности, если ошибка приводит к перенаправлению или передаче данных по конвейеру в той или иной форме. Если сбой молчит или возвращает значение по умолчанию, я также проверяю, что это действительно происходит.
Вы, ребята, еще можете finish the job before the deadline?
The first pass deadline around here is always slightly "soft" to account for testing and any issues that crop up. I find that if you use a plain old pencil and some graph paper or a whiteboard that you can easily figure out a basic set of tests before you even write any code. With this approach you might find a project takes 25% more time up front but that over the entire lifecycle of the app you will easily save the 25% you spent up front by not having as many issues further down the pipeline.
I edited this to add in some links to look at for both actual testing techniques and as a way to get a visual sense of how they come together.
- http://bakery.cakephp.org/articles/view/testing-models-with-cakephp-1-2-test-suite
- http://book.cakephp.org/view/160/Testing
- http://debuggable.com/posts/unit-testing-in-cakephp-part-1---introduction-to-unit-testing:48102610-c5d0-4398-a010-76974834cda3
- http://mark-story.com/nodes/view/testing-cakephp-controllers-the-hard-way
Also, I have to agree and disagree with the cake devs on writing tests. It is a very good idea to test anything you want to reuse - be it a single component file or a complex plugin - since you will be distributing it and the tests both show working code and are great examples of what can be done with a piece of code.
As for not testing controllers because you have to use mock objects - that is just a weak excuse not to do a little bit of tricky work that once you bother with it becomes quite a bit easier each time you do it and it really, really does cut down the error rate and gives you a huge increase in your own understanding of your own code.
Вы можете взглянуть на this .
Я не очень хорошо знаком с CakePHP, но обычно использую PHPUnit. Я использую Netbeans, который довольно хорошо интегрирует PHPUnit (не знаю, подходит ли вам этот вариант). Можно запускать модульные тесты независимо от того, какой веб-фреймворк вы используете.
Я обычно тестирую все возможности подключения к источникам данных (весь уровень доступа к данным) и гарантирую, что постоянство работает должным образом. Кроме того, если у вас есть какая-либо бизнес-логика в вашем приложении, протестируйте ее , чтобы вы знали, что она действительно работает. У меня нет большого опыта в тестировании, но я предполагаю, что другие предложат вам проверить свои взгляды. Лично я использую для этого в браузере F5, хе-хе :). Когда дело доходит до функциональности AJAX, я проверяю каждый его бит (что запрос выполняет свое дело и / или получает желаемый результат).
Что касается времени / дедлайнов, то одно можно сказать наверняка - это то, что ваш проект выиграет от тестирования. Вероятность превышения крайнего срока намного выше, если не использовать какую-либо форму тестирования, чтобы убедиться, что строительные блоки вашего приложения работают так, как вы хотите. Допустим, ваше приложение становится больше (что происходит в большинстве случаев), у вас нет модульных тестов и ваше приложение не работает. Как узнать, где отлаживать, и сколько еще времени вы бы потратили на поиск проблемы? Главное понять, что гарантия того, что небольшие фрагменты кода работают, действительно важна, когда вы получаете много таких небольших фрагментов.
Время, потраченное на написание тестов, может показаться непродуктивным, поскольку он не ведет напрямую к функциональности, но со временем играет действительно важную роль. Считайте это формой страхования.