тестируете ли вы свой код?
если да (TDD, BDD..., не обязательно driven, в первую очередь автоматически), то как?
|
да, надо было открытый опрос сделать...
|
Проблема в том, что неясно, как тестировать интерфейс.
|
Или самый простой пример. Есть функция getDocumentSize, которая вычисляет размер документа. Как для неё тест написать?
|
Цитата:
А также поведение на слабой и средней по мощности машине + mobile. Тест проходит, только если работает на всех, за исключением особенностей мобильных версий. Каких-то одинаковых тестов нет. Если подскажете хороший инструмент, будет здорово. |
Цитата:
|
Цитата:
jasmine, selenium, Watir, sahi, mink, behat jspec, Screw.Unit, Dojo Objective Harness, JavaScriptMVC Цитата:
единственный вариант, подменять getViewportSize и getRootElement. Вообще я вижу два пути как начинать: 1) после каждой ошибки думать, как ее можно было бы избежать с помощью тестов и предпринимать действия, 2) писать тесты, когда это не сложно, при этом сложно со временем должно превращаться в несложно. Ну и в результате должны прийти либо к некоторому разумному покрытию тестами, либо к максимально возможному (что-то один из вариантов явно звучит утопично :) тоже разумному не хватает что ли...). В любом случае надо пробовать иначе ничего не понятно... Цитата:
Цитата:
я тут полазил по сети и решил поделиться тем, что нашел (опять же, не обязательно ориентировано на javascript): Testing Backbone applications with Jasmine and Sinon Tips for Unit Testing Introducing BDD Developer Testing and the Importance of Context Mocks Aren't Stubs Цитата:
Цитата:
Цитата:
|
Цитата:
Цитата:
|
Цитата:
function getViewportSize() { return [1, 1]; }
function getRootElement() { return {scrollWidth: 2, scrollHeight: 2}; }
|
Как мне это поможет проверить правильность определения размеров документа? Фишка-то в том, что чтобы проверить правильность размеров, нужно определить размеры. Рекурсия.
То же самое с позицией элемента. |
Цитата:
|
x-yuri, функция получения размеров документа - 2 строчки кода. там нечего тестировать. эти 2 строчки в отрыве от всего остального тестировать вообще нет никакого смысла. именно поэтому 90% модульных тестов - мусор. лучше применять так называемые каскадные тесты. когда модули тестируются без отрыва от окружения, полагаясь на то, что модули ими используемые уже протестированы.
|
Kolyaj, в данном случае нужно создать документ заданой наперёд высоты и проверить совпадают ли вычисленные этой функцией значения с эталонными.
|
|
Цитата:
|
никак. некоторым функциям нужно просто доверять.
|
Ну вот именно этой доверять не хочется :)
|
почему? есть основания ей не доверять?
|
Даже не представляю как работать с динамическими языками без тестов/спецификаций, использую Jasmine.
Например, тестирование логики (простенький IoC / DI) https://github.com/alexeypetrushin/r...on_spec.coffee сам код https://github.com/alexeypetrushin/r...jection.coffee Тестирование интерфейса (Backbone.js) https://github.com/alexeypetrushin/r...es_spec.coffee сам код https://github.com/alexeypetrushin/r...ntities.coffee Про то что все не протестировать и про кроссбраузерность: Да, но есть хорошая новость - ошибки в програмных продуктах подчиняются закону Парето (power law) и распределены нелинейно. Хорошая - потому что можно писать всего-лишь простейшие тесты для 20% функционала и это позволит отловить более 80% всех ошибок. Про кроссбраузерность - можно селениумом тестровать, но это уже сложно. П.С. кстати, кто использует Jasmine (особенно6 если используете ее с CoffeeScript), может буде интересно, вот эта штука http://alexeypetrushin.github.com/mary позволяет поменять форму записи expectation и писать 'Mary'.should match: /ry/ или 'Mary'.should().match /ry/ вместо expect('Mary').toMatch(/ry/) |
Вторым, не таким видимым но не менее значимым достоинством спецификаций (BDD/TDD) является то что без них невозможны все эти refactoring, SCRUM, agile, прочие методологии.
Потому что ключевой компонент всех этих методик - возможность развивать проект мелкими итеративными шагами, или, говоря другими словами - возможность быстрого и безболезненного внесения правок в код проекта. А без тестов это невозможно, потому что хрен знает будет ли проект работать после этой, даже очень маленькой правки. И эта неявная проблема - высокая стоимость внесения изменений (потому что после каждой правки нужно тратить время на ручное тестирование) может тормозить развитие проекта. |
есть идея попробовать написать несложное веб-приложение под руководством DjDiablo. Я предлагаю написать todo (веб-приложение в смысле, а не todo для веб-приложения). Есть ли есть идеи, можете предлагать.
|
Спасибо за предложение.
Todo веб приложение, и тодо как компонент для джумлы (к примеру), не имеют таких уж больших различий. Ну за исключением того что компонент по любому пишется на Joomla Framework, а с фреймворком для самостоятельного приложения мы вправе определиться сами, ну и некоторые вещи из cms придется дописать, типа авторизации. Предложенная задача прекрасно решается в рамках jqueryui, и голого php или любого php фреймворка. Если уж есть люди которым это интересно, я нарисую проект а потом можно его обсудить. А дальше и написать. Если говорить шире, есть некая критическая точка в разработке, когда сложность приложения превышает сложность используемый функционал платформы на которой это приложение разработано. Грубо говоря вы используете 100 методов из фреймворка, и 1000 методов разработанных вами же. Вот когда это происходит тогда и начинается настоящие веселье. Потому что нужно собрать свои мысли в кучу, упорядочить действия, спланировать, предусмотреть, то есть нужно думать и плавать в своём же "говне" :) , справочник по jqiuery тут уже неспасёт :). Этот проект проблематику не раскроет конечно, но для затравки сойдёт пожалуй. |
| Часовой пояс GMT +3, время: 16:57. |