|
|
|||||
Lorem ipsum
|
Ххаха! Точняк =)
__________________
Поймай яблоко 2! |
|
|||||
Регистрация: May 2003
Адрес: Tallinn
Сообщений: 3,181
|
Пример простого юнит теста на flexunit:
package { import org.flexunit.asserts.assertEquals; public class MyCoolModelTest { private var model:IMyCoolModel; [Before] public function setUp():void { model = new MyCoolModel(); } [After] public function tearDown():void { } [test] public function testCountResult():void { model.countResult(5, 3); assertEquals(model.result, 15); } } } public class MyCoolModel implements IMyCoolModel { private var _result:int; public function countResult(a:int, b:int):void { _result = a * b; } public function get result():int { return _result; } } |
|
|||||
Цитата:
А что за Before After?
__________________
Чтобы доказать, что вы не робот, причините вред другому человеку. |
|
|||||
Регистрация: May 2003
Адрес: Tallinn
Сообщений: 3,181
|
на эту тему полно книжек и инфы в гугле.
Например, если кто-то изменит чтото в логике MyCoolModel, countResult всё равно должен выдавать 15 при данных 5 и 3. Если этого не происходит, значит баг в логике. Соответственно во время сборки проекта, вылетит ошибка, что с MyCoolModel что-то не то. Так яснее? |
|
|||||
Modus ponens
|
Давно не прикасался ни к Флешу ни к вебу вообще. Работаю в компании которая разрабатывает файловую систему в отделе инфраструктуры (пишу программы для тестирования нашего продукта, но не сами тесты).
По поводу юнит тестов: ну тестировать программы вообще нужно - я надеюсь с этим никто не спорит? Юнит тест подразумевает тестирование "атомарных" или "неделимых" частей программы - одной функции, одного класса и т.п. За написание юнит тестов отвечает программист пишуший тестируемый код. Как правило юнит тесты не работают с настоящими ресурсами (типа баз данных, сетевых подключений и т.п.) а с имитациями (т.как скорость тестирования важна). Юнит тесты - часть сборки проекта. Следующая ступенька в тестировании: тесты интеграции. Это когда несколько "атомарных" частей кода нужно протестировать на взаимодействие. Их тоже пишут программисты, но их не запускают во время сборки, т.как сборка может легитимно не пройти такой тест. Следующая ступенька - тесты на приемлимость (acceptance). Эти тесты пишут тестеры совместно с разработчиками. Эти тесты запускаются в процессе упаковки продукта (на основной ветке репозитория / релизных ветках). Как правило эти тесты запускаются врезультате мерджей ветки разработчика в мастер / релиз. Назначение таких тестов - предотвратить очевидные недостатки типа "программа не запускается", "части программы не хватает". Нужно это для того, чтобы не посылать тестерам явно неработающие сборки. Следующая ступенька - "слепые" (black box) тесты. Их пишут тестеры исходя из спецификации продукта. Как правило эти тесты имитируют взаимодействие пользователя с продуктом, занимают много времени (как минимум несколько часов в день, но может и круглый день). Отдельно есть еще тесты на эффективность, устойчивость против ошибок окружения и много чего еще. Все зависит от отжидаемого качества продукта и наличных ресурсов для разработки.
__________________
Hell is the possibility of sanity Последний раз редактировалось wvxvw; 16.06.2016 в 16:28. |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
1) Что нельзя бить карту другой мастью. 2) Что можно бить карту той же мастью, но выше по рангу. 3) Что нельзя бить карту той же мастью, но ниже по рангу. 4) Что можно бить что угодно козырем. Эти 4 теста дают неплохое покрытие для этого метода. Реализовали, запустили, тесты зелёные. Что это значит? Значит что мне не нужно тестировать это вручную больше никогда. Я всегда знаю, что метод canBeat вернёт правильный результат. После лёгкого QA-теста выяснилось, что младший козырь может бить верхний козырь – это баг. Что я делаю? Я делаю пятый тест на этот метод: 5) Козырь нижнего ранга не бьёт козыря верхнего ранга. Это гарантия того, что этот баг больше никогда не повторится. Через месяц мне пришлось добавить джокеров с условиями, что джокеры бьют всё подряд. Я исправляю старый метод canBeat, добавляя в него новую логику, но тесты позволяют мне быть уверенным, что я не ничего не сломаю. Поведение старых карт относительно друг друга не изменилось. Покрывая всё приложение тестами я могу свободно проводить рефакторинг кишков не боясь, что где-то что-то сломается. Тесты я запускаю каждый раз (имею ввиду вообще все) перед тем как сделать коммит и каждый раз после того, как я сделал что-то сложное. Например, немного поменял архитектуру и хочу узнать, как это аукнется. И я узнаю это за несколько минут, пока отхожу сварить себе кофе. Добавлено через 3 минуты Цитата:
1) 2 + 2 = 4 2) 2 + 2 * 2 = 6 3) (2 + 2) * 2 = 8 4) ( 2 * (3 - 2) + 4 ) * 3 = 18 ты за пару секунд узнаешь, работает ли твоя программа правильно. Вручную прогонять все 20 тестов при каждом исправлении логики... избавьте. Добавлено через 9 минут Цитата:
Вообще из этого краткого рассказа подход очень похож на тестирование в Google.
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Modus ponens
|
Когда работаешь, иногда нужно либо специально создать некорректную ситуацию, или просто уже знаешь о проблеме в другом модуле, но не ждать же, когда его починят. Когда проблема в двух взаимосвязаных модулях кому-то обязательно прийдется первым написать код не работающий с другим модулем.
Например, не далее чем вчера, обнаружил, что на бумаге заявлено что NFS подключений к нашему серверу может быть одновременно 1000, но на практике оказалось, что не больше 200. Я пишу код NFS клиента. Поговорил с программистами, которые делают сервер - они исправили ошибку, но правки пошли в мастер ветку. Кроме мастера, есть релизные ветки, куда это изменение не пойдет, но их все еще нужно тестировать. Код, который я пишу - заказчику не отправляется, он только для внутреннего использования. Мне нет смысла писать две версии клиента - одну с учетом ошибки сервера, а другую - без. Соответственно, я просто пишу версию, которая рассчитывает на 1000 подключений и оформляю баг-репорт для серверной команды. Если баг не исправят до релиза - заказчику просто уйдет программа с описанием известных недостатков, где будет сказано, что подключений может быть не больше 200. Но все это практика больших компаний / продуктов с другими требованиями. Тут она финансово оправдана. Я подозреваю, что будет тяжело опрадвать подобную бюрократию для казуальных веб игр, например.
__________________
Hell is the possibility of sanity |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Понятно, спасибо!
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Цитата:
Как по мне, так минусы юнит тестов такие: 1) Не для любого кода можно написать юнит тест. Часто все равно придется делать полную сборку проекта 2) Часто уходит много времени уже на то, чтобы приудмать как лучше написать этот тест (или как вообще его написать). Хотя я и сам могу представить ситуацию, когда действительно лучше сделать юнит тест. Например если сборка проекта (буду говорить об игре, так как я занимаюсь именно играми) и дохождение до определенного места, где будет происходить какое-то действие, занимает достаточно много времени. Например персонаж должен кидать гранату, и траектория ее полета зависит он некоторых факторов, таких как направление и сила ветра, к примеру. Все это передается в качестве параметров метода, рассчитывающего траекторию. Так вот в этом случае будет проще и быстрее написать отдельный тест именно для этого метода, даже без персонажа, который просто будет рисовать траекторию, по разным входящим данным, и проследить что там происходит, если ввести что-нибудь не то, например нулевой вектор направления, или нулевую силу ветра. Да, реальный пример, в котором юнит тесты рулят. Но писать их практически для всего и вся, нет уж, увольте)
__________________
Ко мне можно и нужно обращаться на ты) |
|
|||||
Регистрация: Dec 2010
Адрес: Ярославль
Сообщений: 1,255
|
Цитата:
|
Часовой пояс GMT +4, время: 02:30. |
|
« Предыдущая тема | Следующая тема » |
|
|