тестируете ли вы свой код?

[x-yuri]

Как мне это поможет проверить правильность определения размеров документа?

это не поможет тебе проверить правильность определения размеров. Это поможет тебе проверить, что сама функция работает правильно. White box testing. Можешь статью Фаулера почитать про моки и заглушки. И да, я не уверен, что надо так тестировать. Я выше писал, что кросс-браузерность автоматически не протестируешь. Хотя может быть что-то можно протестировать с помощью инструментов выше, я еще не разбирался детально. Но там писалось про интеграцию в браузеры.

[tenshi]

x-yuri, функция получения размеров документа - 2 строчки кода. там нечего тестировать. эти 2 строчки в отрыве от всего остального тестировать вообще нет никакого смысла. именно поэтому 90% модульных тестов - мусор. лучше применять так называемые каскадные тесты. когда модули тестируются без отрыва от окружения, полагаясь на то, что модули ими используемые уже протестированы.

[tenshi]

Kolyaj, в данном случае нужно создать документ заданой наперёд высоты и проверить совпадают ли вычисленные этой функцией значения с эталонными.

[tenshi]

ну и на правах рекламы:

http://nin-jin.github.com/web-compon...doc.xml?LO858F

[Kolyaj]

Kolyaj, в данном случае нужно создать документ заданой наперёд высоты и проверить совпадают ли вычисленные этой функцией значения с эталонными.

Ну ок, давай чуть усложним задачу. Нужно протестировать функцию вычисления размеров viewport-а. Как ты создашь страницу с заранее заданными размерами окна, да ещё чтобы они были одинаковы во всех браузерах?

[tenshi]

никак. некоторым функциям нужно просто доверять.

[Kolyaj]

Ну вот именно этой доверять не хочется

[tenshi]

почему? есть основания ей не доверять?

[axyd]

Даже не представляю как работать с динамическими языками без тестов/спецификаций, использую 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/)

[axyd]

Вторым, не таким видимым но не менее значимым достоинством спецификаций (BDD/TDD) является то что без них невозможны все эти refactoring, SCRUM, agile, прочие методологии.
Потому что ключевой компонент всех этих методик - возможность развивать проект мелкими итеративными шагами, или, говоря другими словами - возможность быстрого и безболезненного внесения правок в код проекта.

А без тестов это невозможно, потому что хрен знает будет ли проект работать после этой, даже очень маленькой правки.
И эта неявная проблема - высокая стоимость внесения изменений (потому что после каждой правки нужно тратить время на ручное тестирование) может тормозить развитие проекта.