13.10.2011, 03:14
|
|
|
|
Регистрация: 27.12.2008
Сообщений: 4,201
|
|
тестируете ли вы свой код?
если да (TDD, BDD..., не обязательно driven, в первую очередь автоматически), то как?
Последний раз редактировалось x-yuri, 13.10.2011 в 06:37.
|
|
13.10.2011, 13:57
|
|
|
|
Регистрация: 27.12.2008
Сообщений: 4,201
|
|
да, надо было открытый опрос сделать...
|
|
13.10.2011, 14:05
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Проблема в том, что неясно, как тестировать интерфейс.
|
|
13.10.2011, 14:06
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Или самый простой пример. Есть функция getDocumentSize, которая вычисляет размер документа. Как для неё тест написать?
|
|
13.10.2011, 17:42
|
|
猫
|
|
Регистрация: 07.06.2007
Сообщений: 7,504
|
|
Сообщение от Kolyaj
|
Проблема в том, что неясно, как тестировать интерфейс.
|
В основном интерфейс тестирую, посредством создания множества однотипных объектов. Автоматически никак. Смотрю на процессор и поедаемый объем памяти.
А также поведение на слабой и средней по мощности машине + mobile. Тест проходит, только если работает на всех, за исключением особенностей мобильных версий. Каких-то одинаковых тестов нет. Если подскажете хороший инструмент, будет здорово.
__________________
Последний раз редактировалось Gozar, Сегодня в 24:14.
|
|
13.10.2011, 17:47
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Сообщение от Gozar
|
В основном интерфейс тестирую, посредством создания множества однотипных объектов. Автоматически никак. Смотрю на процессор и поедаемый объем памяти.
|
Ну это на быстродействие, как я понимаю. Как тестировать на правильное отображение и функционал?
|
|
14.10.2011, 02:50
|
|
|
|
Регистрация: 27.12.2008
Сообщений: 4,201
|
|
Сообщение от Kolyaj
|
Проблема в том, что неясно, как тестировать интерфейс.
|
ну вот, а я думал, что вы мне все расскажете На самом деле, слишком общий вопрос. Может быть с помощью какого-нибудь из этих инструментов (возможно не все из них предназначены для тестирования javascript-кода):
jasmine, selenium, Watir, sahi, mink, behat
jspec, Screw.Unit,
Dojo Objective Harness, JavaScriptMVC
Сообщение от Kolyaj
|
Или самый простой пример. Есть функция getDocumentSize, которая вычисляет размер документа. Как для неё тест написать?
|
https://github.com/Kolyaj/CrossJS/bl...cross.js#L2034
единственный вариант, подменять getViewportSize и getRootElement. Вообще я вижу два пути как начинать: 1) после каждой ошибки думать, как ее можно было бы избежать с помощью тестов и предпринимать действия, 2) писать тесты, когда это не сложно, при этом сложно со временем должно превращаться в несложно. Ну и в результате должны прийти либо к некоторому разумному покрытию тестами, либо к максимально возможному (что-то один из вариантов явно звучит утопично тоже разумному не хватает что ли...). В любом случае надо пробовать иначе ничего не понятно...
Сообщение от Gozar
|
Если подскажете хороший инструмент, будет здорово.
|
возможно что-то из ссылок выше
Сообщение от Kolyaj
|
Ну это на быстродействие, как я понимаю. Как тестировать на правильное отображение и функционал?
|
ну кросс-браузерность ты автоматически не протестируешь, если ты об этом...
я тут полазил по сети и решил поделиться тем, что нашел (опять же, не обязательно ориентировано на 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
|
|
14.10.2011, 09:11
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Сообщение от x-yuri
|
ну кросс-браузерность ты автоматически не протестируешь, если ты об этом...
|
Я готов каждый браузер руками запускать и открывать там нужную страницу
Сообщение от x-yuri
|
единственный вариант, подменять getViewportSize и getRootElement.
|
На что подменять? Я же не знаю, какой будет размер у документа. Можно чего-то рисовать на странице, а потом проверять правильность, но это утомительно и рисовать, и проверять.
|
|
15.10.2011, 00:36
|
|
|
|
Регистрация: 27.12.2008
Сообщений: 4,201
|
|
Сообщение от Kolyaj
|
На что подменять?
|
условно так:
function getViewportSize() { return [1, 1]; }
function getRootElement() { return {scrollWidth: 2, scrollHeight: 2}; }
|
|
15.10.2011, 09:19
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Как мне это поможет проверить правильность определения размеров документа? Фишка-то в том, что чтобы проверить правильность размеров, нужно определить размеры. Рекурсия.
То же самое с позицией элемента.
|
|
|
|