Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flasher.ru > Флейм

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 16.06.2016, 13:15
Zebestov вне форума Посмотреть профиль Отправить личное сообщение для Zebestov Посетить домашнюю страницу Zebestov Найти все сообщения от Zebestov
  № 31  
Ответить с цитированием
Zebestov
Lorem ipsum
 
Аватар для Zebestov

модератор форума
Регистрация: May 2001
Адрес: Одесса
Сообщений: 4,869
Записей в блоге: 4
Цитата:
Сообщение от GBee Посмотреть сообщение
Такая секретная технология, что по ней инфы много, но нормального примера нет. И тот, кто ее познал почему то тоже не может внятный пример показать.
Ххаха! Точняк =)
__________________
Поймай яблоко 2!

Старый 16.06.2016, 13:42
CrazyFlasher вне форума Посмотреть профиль Отправить личное сообщение для CrazyFlasher Найти все сообщения от CrazyFlasher
  № 32  
Ответить с цитированием
CrazyFlasher
 
Аватар для CrazyFlasher

Регистрация: May 2003
Адрес: Tallinn
Сообщений: 3,181
Пример простого юнит теста на flexunit:
Код AS3:
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);
		}
	}
}
Код AS3:
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;
	}
}
Код AS3:
public interface IMyCoolModel
{
	function countResult(a:int, b:int):void;
	function get result():int;
}
__________________
Flash Developer
Папа TDP4 Team Battle

Старый 16.06.2016, 13:52
GBee вне форума Посмотреть профиль Отправить личное сообщение для GBee Найти все сообщения от GBee
  № 33  
Ответить с цитированием
GBee
 
Аватар для GBee

Регистрация: Jan 2009
Сообщений: 3,067
Записей в блоге: 3
Отправить сообщение для GBee с помощью Skype™
Цитата:
Пример простого юнит теста на flexunit:
Вот о чем и речь. Такие примеры показывают как их можно использовать, но не показывают смысла их использования.

А что за Before After?
__________________
Чтобы доказать, что вы не робот, причините вред другому человеку.

Старый 16.06.2016, 14:08
CrazyFlasher вне форума Посмотреть профиль Отправить личное сообщение для CrazyFlasher Найти все сообщения от CrazyFlasher
  № 34  
Ответить с цитированием
CrazyFlasher
 
Аватар для CrazyFlasher

Регистрация: May 2003
Адрес: Tallinn
Сообщений: 3,181
на эту тему полно книжек и инфы в гугле.
Например, если кто-то изменит чтото в логике MyCoolModel, countResult всё равно должен выдавать 15 при данных 5 и 3. Если этого не происходит, значит баг в логике. Соответственно во время сборки проекта, вылетит ошибка, что с MyCoolModel что-то не то.
Так яснее?
__________________
Flash Developer
Папа TDP4 Team Battle

Старый 16.06.2016, 14:37
wvxvw вне форума Посмотреть профиль Отправить личное сообщение для wvxvw Найти все сообщения от wvxvw
  № 35  
Ответить с цитированием
wvxvw
Modus ponens
 
Аватар для wvxvw

модератор форума
Регистрация: Jul 2006
Адрес: #1=(list #1#)
Сообщений: 8,049
Записей в блоге: 38
Давно не прикасался ни к Флешу ни к вебу вообще. Работаю в компании которая разрабатывает файловую систему в отделе инфраструктуры (пишу программы для тестирования нашего продукта, но не сами тесты).

По поводу юнит тестов: ну тестировать программы вообще нужно - я надеюсь с этим никто не спорит?
Юнит тест подразумевает тестирование "атомарных" или "неделимых" частей программы - одной функции, одного класса и т.п. За написание юнит тестов отвечает программист пишуший тестируемый код. Как правило юнит тесты не работают с настоящими ресурсами (типа баз данных, сетевых подключений и т.п.) а с имитациями (т.как скорость тестирования важна). Юнит тесты - часть сборки проекта.

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

Следующая ступенька - тесты на приемлимость (acceptance). Эти тесты пишут тестеры совместно с разработчиками. Эти тесты запускаются в процессе упаковки продукта (на основной ветке репозитория / релизных ветках). Как правило эти тесты запускаются врезультате мерджей ветки разработчика в мастер / релиз. Назначение таких тестов - предотвратить очевидные недостатки типа "программа не запускается", "части программы не хватает". Нужно это для того, чтобы не посылать тестерам явно неработающие сборки.

Следующая ступенька - "слепые" (black box) тесты. Их пишут тестеры исходя из спецификации продукта. Как правило эти тесты имитируют взаимодействие пользователя с продуктом, занимают много времени (как минимум несколько часов в день, но может и круглый день).

Отдельно есть еще тесты на эффективность, устойчивость против ошибок окружения и много чего еще. Все зависит от отжидаемого качества продукта и наличных ресурсов для разработки.
__________________
Hell is the possibility of sanity


Последний раз редактировалось wvxvw; 16.06.2016 в 16:28.
Старый 16.06.2016, 22:45
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 36  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
Цитата:
Ну не знай, что-то я сомневаюсь, что для небольших инди проектов, тесты действительно так нужны. Лучше потратить это время на контент, чем на создание тестов, которые отработают один раз и будут лежать мёртвым грузом. Тем более, покрывать 100% бизнес логики, это жесть. Иногда достаточно ограничиться обычным дебагером или трейсом, для проверки внутреннего состояния модуля.
Пример от балды: игра в дурака. Что тестируем? Метод #card.canBeat(otherCard), возвращающий true/false.
1) Что нельзя бить карту другой мастью.
2) Что можно бить карту той же мастью, но выше по рангу.
3) Что нельзя бить карту той же мастью, но ниже по рангу.
4) Что можно бить что угодно козырем.

Эти 4 теста дают неплохое покрытие для этого метода. Реализовали, запустили, тесты зелёные. Что это значит? Значит что мне не нужно тестировать это вручную больше никогда. Я всегда знаю, что метод canBeat вернёт правильный результат.
После лёгкого QA-теста выяснилось, что младший козырь может бить верхний козырь – это баг. Что я делаю? Я делаю пятый тест на этот метод:
5) Козырь нижнего ранга не бьёт козыря верхнего ранга.
Это гарантия того, что этот баг больше никогда не повторится.

Через месяц мне пришлось добавить джокеров с условиями, что джокеры бьют всё подряд. Я исправляю старый метод canBeat, добавляя в него новую логику, но тесты позволяют мне быть уверенным, что я не ничего не сломаю. Поведение старых карт относительно друг друга не изменилось.
Покрывая всё приложение тестами я могу свободно проводить рефакторинг кишков не боясь, что где-то что-то сломается. Тесты я запускаю каждый раз (имею ввиду вообще все) перед тем как сделать коммит и каждый раз после того, как я сделал что-то сложное. Например, немного поменял архитектуру и хочу узнать, как это аукнется. И я узнаю это за несколько минут, пока отхожу сварить себе кофе.

Добавлено через 3 минуты
Цитата:
Вот о чем и речь. Такие примеры показывают как их можно использовать, но не показывают смысла их использования.
Смысл - в простом рефакторинге и в уверенности, что новые фичи не сломают старые. Бонусом - простота разработки; например, перед тобой поставили задачу - написать калькулятор, вычисляющий длинные выражения. Единожды написав 20 тестов, которые тестируют вложенности скобок, порядок операторов, типа
1) 2 + 2 = 4
2) 2 + 2 * 2 = 6
3) (2 + 2) * 2 = 8
4) ( 2 * (3 - 2) + 4 ) * 3 = 18

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

Добавлено через 9 минут
Цитата:
Следующая ступенька в тестировании: тесты интеграции. Это когда несколько "атомарных" частей кода нужно протестировать на взаимодействие. Их тоже пишут программисты, но их не запускают во время сборки, т.как сборка может легитимно не пройти такой тест.
@wvxvw Любопытно, почему сборка может не проходить интеграционный тест? Это ведь именно самый важный маркер, дружит ли система сама с собой. Если модуль А ожидает параметр int ID, а модуль B ему даёт string Name (для примера скажем, что типизация динамическая и ошибку в компайл-тайм не отследить) – то это как раз самое время сказать, что со сборкой что-то не то.

Вообще из этого краткого рассказа подход очень похож на тестирование в Google.

Старый 17.06.2016, 13:41
wvxvw вне форума Посмотреть профиль Отправить личное сообщение для wvxvw Найти все сообщения от wvxvw
  № 37  
Ответить с цитированием
wvxvw
Modus ponens
 
Аватар для wvxvw

модератор форума
Регистрация: Jul 2006
Адрес: #1=(list #1#)
Сообщений: 8,049
Записей в блоге: 38
Когда работаешь, иногда нужно либо специально создать некорректную ситуацию, или просто уже знаешь о проблеме в другом модуле, но не ждать же, когда его починят. Когда проблема в двух взаимосвязаных модулях кому-то обязательно прийдется первым написать код не работающий с другим модулем.

Например, не далее чем вчера, обнаружил, что на бумаге заявлено что NFS подключений к нашему серверу может быть одновременно 1000, но на практике оказалось, что не больше 200. Я пишу код NFS клиента. Поговорил с программистами, которые делают сервер - они исправили ошибку, но правки пошли в мастер ветку. Кроме мастера, есть релизные ветки, куда это изменение не пойдет, но их все еще нужно тестировать. Код, который я пишу - заказчику не отправляется, он только для внутреннего использования. Мне нет смысла писать две версии клиента - одну с учетом ошибки сервера, а другую - без. Соответственно, я просто пишу версию, которая рассчитывает на 1000 подключений и оформляю баг-репорт для серверной команды.

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

Но все это практика больших компаний / продуктов с другими требованиями. Тут она финансово оправдана. Я подозреваю, что будет тяжело опрадвать подобную бюрократию для казуальных веб игр, например.
__________________
Hell is the possibility of sanity

Старый 18.06.2016, 11:52
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 38  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
Понятно, спасибо!

Старый 18.06.2016, 19:29
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 39  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Я подозреваю, что будет тяжело опрадвать подобную бюрократию для казуальных веб игр, например.
Собственно, даже не для совсем казуальных, такая практика тоже лишний гемор.
Как по мне, так минусы юнит тестов такие:
1) Не для любого кода можно написать юнит тест. Часто все равно придется делать полную сборку проекта
2) Часто уходит много времени уже на то, чтобы приудмать как лучше написать этот тест (или как вообще его написать).

Хотя я и сам могу представить ситуацию, когда действительно лучше сделать юнит тест. Например если сборка проекта (буду говорить об игре, так как я занимаюсь именно играми) и дохождение до определенного места, где будет происходить какое-то действие, занимает достаточно много времени. Например персонаж должен кидать гранату, и траектория ее полета зависит он некоторых факторов, таких как направление и сила ветра, к примеру. Все это передается в качестве параметров метода, рассчитывающего траекторию. Так вот в этом случае будет проще и быстрее написать отдельный тест именно для этого метода, даже без персонажа, который просто будет рисовать траекторию, по разным входящим данным, и проследить что там происходит, если ввести что-нибудь не то, например нулевой вектор направления, или нулевую силу ветра. Да, реальный пример, в котором юнит тесты рулят. Но писать их практически для всего и вся, нет уж, увольте)
__________________
Ко мне можно и нужно обращаться на ты)

Старый 18.06.2016, 21:40
illuzor вне форума Посмотреть профиль Отправить личное сообщение для illuzor Найти все сообщения от illuzor
  № 40  
Ответить с цитированием
illuzor
 
Аватар для illuzor

Регистрация: Dec 2010
Адрес: Ярославль
Сообщений: 1,255
Цитата:
Например персонаж должен кидать гранату, и траектория ее полета зависит он некоторых факторов, таких как направление и сила ветра, к примеру. Все это передается в качестве параметров метода, рассчитывающего траекторию. Так вот в этом случае будет проще и быстрее написать отдельный тест именно для этого метода, даже без персонажа, который просто будет рисовать траекторию, по разным входящим данным, и проследить что там происходит, если ввести что-нибудь не то, например нулевой вектор направления, или нулевую силу ветра.
Это больше похоже на функциональность для дебажной версии, чем на тесты. То есть, собственный код игры, а не внешний тестирующий код. Мы подобное всегда называли читами. Естественно, в релизной версии все читы вырезаются. Или почти все

Создать новую тему Ответ Часовой пояс GMT +4, время: 16:37.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 16:37.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.