LINUX.ORG.RU

frontend тестирование

 , ,


1

2

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

model = new Backbone.Model()

model.set foo: 'bar'

model.get('foo').expectTo('bar')

это же мрак. но именно это описано во всех статьях. я же не хочу тратить лишнее время ради галочки, я хочу наоборот меньше работать (меньше багов, меньше хотфиксов, меньше тестировщиков).

как тестировать html-css, можно ли тестировать кроссбраузерность?

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

ps понимаю, пост немного сумбурный, но заголовок более чем выражает всю его суть. жажду лучших практик, что отфильтровать а что выбрать и т.п.

★★★

Последнее исправление: trashymichael (всего исправлений: 4)

буду сам тут немного отписывать.

вот сейчас я читаю про жасмин, вроде годный инструмент. жасмин, бекбон. в туториале, опять же, тестируют вещи типа

var foo = 1
assert(foo == 1)

я активно юзаю бекбон со всеми вытекающими. зачем мне это тестировать. зачем мне тестировать сеттеры геттеры, ведь бекбон и так оттестирован. нужно ли покрывать тестом метод типа

function parse (response) { return response.objects }

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

trashymichael ★★★
() автор топика

HTML тестировать умеет Lint и прочие HTML-валидаторы, для JS тоже есть валидаторы, и отладчики. CSS валидаторами тоже не обделён, вроде... А вот кроссбраузерность тестировать приходится ручками, с привлечением различных версий браузеров в различных ОС, которые запускать приходится в виртуалках. Других вариантов пока не изобрели...

lucentcode ★★★★★
()

можно ли тестировать кроссбраузерность?

Очевидно же, в продакшне, по матам от юзеров.

Есть всякие browsershots.org, но толку от них мало.

Kalashnikov ★★★
()
Ответ на: комментарий от lucentcode

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

trashymichael ★★★
() автор топика

как тестировать html-css, можно ли тестировать кроссбраузерность?

Нанимаешь толпу «мартышек» и они тебе сравнивают твою страничку в разных браузерах. Такая вот автоматизация процесса.

Boba_Fett
()
Ответ на: комментарий от Boba_Fett

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

trashymichael ★★★
() автор топика
Ответ на: комментарий от trashymichael

Уже доехало, Jasmine(на сколько я знаю) используется для юнит-тестирования Java-script. А headless-браузер - это различные вариации WebKit? Сомневаюсь, что IE бывает в headless-режиме. Протестировать JS - дело годное, а что касается HTML/CSS - так написать юнит-тесты, проверяющие корректную работу бэкенда в различных браузерах просто не возможно. Благодарные пользователи сами пошлют вам сообщение, как только в их любимом шестом IE вёрстка поедет, или что-то не так отобразится.

lucentcode ★★★★★
()

Use mocha Luke!

http://visionmedia.github.com/mocha/

Вообще, для тестирования GUI (headless в том числе) в RoR есть гем Capybara (Capybara-webkyt), что касается без привязки к RoR - х.з. НАсчёт кросс-браузерности, думаю, не автоматизировать это, там в основном стили проверяются визуально.

Reaper ★★
()
Последнее исправление: Reaper (всего исправлений: 2)
Ответ на: комментарий от trashymichael

я понимаю что чудес не бывает, но наверняка есть какие-то приемчики, ну там, хрен знает. сам не знаю чего хочу, да.

Не, ну если только ради пустой болтовни: можно, к примеру, делать автоматический скрин сайта для каждого браузера, затем эти скрины отдавать некой экспертной системе, которая будет сравнивать скрины с эталоном и выдавать те, которые отличаются сильнее, чем на n%. Сравнение изображений с заданным порогом схожести - вроде не такая сложная задача.

Boba_Fett
()

Есть размышления на тему. Я как раз в процессе постижения этого таинства.. Могу сказать, что писать тесты не всегда просто, и не всегда знаешь что именно нужно протестировать (по крайней мере я).

Я слышал.. разные мнения: кто-то говорит, что тестирование не нужно, нет пользы и т.п. (действительно, код либо работает, либо нет, не зависимо от того, обложен он тестами, или нет, но рефакторить потом довольно сложно, да и не только..).

Кто-то говорит, что нужно сначала писать тесты, а потом уже код. Но, нельзя написать тест к тому, чего нет, хоть ты тресни.. В лозунге «сначала тесты потом код» умалчивается о проектировании. А прототипное проектирование вполне себе проектирование. Можно сказать, что сначала пишется прототип кода, затем на его основе тесты, и затем уже затем основной код (если нужно). Иногда необходимый функционал предельно ясен, а потому можно сразу написать тест.

Так же я делаю такую штуку: пишу примерный тест и примерный код, а затем заставляю все это работать.

На серверной стороне я использую rspec вместе с rr, на клиенте jasmine. На руби писать тесты у меня получается лучше, чем на js (вообще-то я пишу на их coffee).

Не знаю как ты отлаживаешь свои программы, но наверно, выводишь какие-то значения на экран, следишь, чтобы они были правильными.. вот это как раз можно оформить ввиде теста.

Дальше, удобно бывает смотреть/запускать/тестировать что-то отдельно от всего остального, например, какое-нибудь окошко. Собственно, все тестирование всегда идет в некой песочнице, куда попадает объект тестирования. В итоге автоматически получается, что компоненты приложения более самостоятельны, и меньше зависят от первоначальной среды, что повышает надежность.

Еще один момент - это некая замена документации.. Я могу забыть как работает компонент, но вспомнить после того как посмотрю тесты.

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

Тестирование не может уберечь от ошибок, которые ты не предусмотрел, оно лишь позволяет убедиться в том, что все работает как ты хотел. bdd сейчас для меня это инструмент разработки, а не автоматизации разработки.. это то, что помогает мне улучшить код в момент его написания.

Как тестировать верстку.. черт его знает.

special-k ★★★
()

phantomjs, а для юнитов в принципе пофиг какой фреймворк.

zz ★★★★
()

для тестирования frontend'а не влезая его код можна использовать selenium и его производные

ZuBB ★★★★★
()
Ответ на: комментарий от lucentcode

про html css я имел ввиду не юнит тестирование. посмотри например тесты жквери, там они проверяют по образцам, например, сравнивая.

trashymichael ★★★
() автор топика
Ответ на: комментарий от special-k

о, никуда не убигай. сейчас я подумаю что еще спросить. а пока прокоментирую твой ответ

тесты перед кодом это и есть tdd, тести не надо писать без кода. когда ты пишешь тест ты уже пишешь и код. не реализацию но интерфейс. то как твой код будет использоваться. это и есть проектирование. только не в контексте «а пусть тут будет так а потом увидим подходит или еще че нужно» а сразу используя, как-то так.

я тоже пишу на кофе. и у меня не страница-скрипты, у меня типа риа одностраничная. понятно что все тестировать надо в изоляции, но надо ли тестировать даже то что расширяет библиотечный код, если кроме предусмотренной библиотеками конфигурации оно ничем не манипулирует (backbone.extends ...).

короче я так думаю надо пробовать, потому буду пробовать и отписывать. если кто-то будет меня поправлять и направлять, буду только рад.

trashymichael ★★★
() автор топика
Ответ на: комментарий от trashymichael

Не знаю, жасмин не использовал, не сравнивал.

Reaper ★★
()
Ответ на: комментарий от trashymichael

Вы про тесты на QUnit, или они там вручную сравнимают на различных браузерах работу своей либы?

lucentcode ★★★★★
()
Ответ на: комментарий от trashymichael

не реализацию но интерфейс

помоему довольно сложно отличить реализацию от интерфейса, я обычно «накидываю» компоненты, смотрю как лучше, а потом уже «фиксирую» тестами.

надо ли тестировать даже то что расширяет библиотечный код, если кроме предусмотренной библиотеками конфигурации оно ничем не манипулирует

приведи пример.

special-k ★★★
()
Последнее исправление: special-k (всего исправлений: 1)
Ответ на: комментарий от special-k

почти все модели, коллекции, они просто расширяют базовые классы. далее, например, события вьювов — делегируются через жиквери. нужно ли тестить эти делегации, жквери и так хорошо тестирован. тоест не совсем понятно что вообще тестить, если почти весь код юзает уже тестированый

trashymichael ★★★
() автор топика
Ответ на: комментарий от trashymichael

кроме возможности тестить факт присутствия сущностей или деклараций, но это уже какой-то перебор помойму

trashymichael ★★★
() автор топика
Ответ на: комментарий от trashymichael

тогда нет, тестировать нужно только нетестированный функционал, я думаю.

special-k ★★★
()
Последнее исправление: special-k (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.