[x-yuri]

Проблема в том, что неясно, как тестировать интерфейс.

ну вот, а я думал, что вы мне все расскажете На самом деле, слишком общий вопрос. Может быть с помощью какого-нибудь из этих инструментов (возможно не все из них предназначены для тестирования javascript-кода):

jasmine, selenium, Watir, sahi, mink, behat

jspec, Screw.Unit,

Dojo Objective Harness, JavaScriptMVC

Или самый простой пример. Есть функция getDocumentSize, которая вычисляет размер документа. Как для неё тест написать?

https://github.com/Kolyaj/CrossJS/bl...cross.js#L2034
единственный вариант, подменять 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

The key point of testing, of course, is that you get good enough test coverage, cheaply enough. This is why unit tests are good: you can test the same things with functional tests, but you can generally do it more easily and cheaply with unit tests. That is why the real trick is not to work harder on writing the tests, but to write code that is more easily testable. When you take this approach, I think you'll find your logic naturally migrating out of pages and into classes.

http://c2.com/cgi/wiki?UnitTest

See ExtremeProgrammingTestingPrivateMethods, and MethodsShouldBePublic. You specifically do not want to test method implementations unless you are really desperate to put in some tests (perhaps when UnitTestingLegacyCode). If the implementation changes, the tests break; not fun. You don't want the tests to force you into a particular implementation. You want the tests to work as scaffolding, not a cage.

http://c2.com/cgi/wiki?UnitTest

I like tests because I am very lazy, somewhat pragmatic, and flagrantly ignorant of established practices. I have no idea whether what I'm doing is what XP calls a unit test (although I suspect I'm pretty close), but from my point of view it doesn't matter much. I do whatever testing makes my whole job easier, and ignore whatever testing makes my whole job harder. If 80% coverage (to pick a number out of the air) is pretty easy to do and has clear benefits, then that's the coverage I get. If 100% coverage is harder than I perceive the benefit to be, then I don't do it. In my mind, there's a curve of cost vs. benefit, and that curve has a sharp knee. I'm looking for that knee when I test.

To my mind, this is the key thing. Not what percentage you are getting for coverage, or do you have a test for every class, or do you test accessors or not, or is it what anybody else is calling a unit test or a functional test. The key thing is that you are paying attention to the benefit you get from your testing, and you push your testing up to the point that the hurt starts to outweigh the benefit and then back off a little. When you find a defect and there was a test you could have done that was easier than having that defect, perhaps next time you'll do that test. When you find that there's a class of defect you test for that turns up so rarely that you feel like you're wasting your time, back off on testing for that class of defect. Then pay attention to what happens. If you were wrong to stop testing for that kind of defect, you'll hurt more. If you were right, you'll hurt less. Hurt is a wonderful feedback mechanism.

Speak, then listen. Throw, then watch. Feedback. Feedback. Feedback.

There's a fair chance that I'm not following established XP practices at all (although it doesn't matter all that much to me). But I hope this does explain how I make testing worth my while. -- WayneConrad

http://c2.com/cgi/wiki?TestEverythin...dPossiblyBreak