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

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

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

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

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

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

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

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

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

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

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