Меню
Что нового?

sergeiklein и целесообразность unit-тестов

  • Автор темы sergeiklein
  • Дата начала

sergeiklein

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

Crazy

Developer
sergeiklein, не пользовался чем? Юнит-тестами? Ничего не имею против, ибо чем меньше конкурентов -- тем лучше.
 

sergeiklein

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

ничем это конечно загон... :) политика тестов есть конечно... и отчеты есть...
 
confguru

confguru

ExAdmin
Команда форума
sergeiklein

Просто твоя фирма (если она есть, еще не доросла)
то TDD :)
Но на внедрение TDD - нужно быть экстремалом в душе.. :)
 
Crazy

Crazy

Developer
admin, не увеличивай конкуренцию. Пусть и дальше думает, что юнит-тесты -- это полное гониво.
 
confguru

confguru

ExAdmin
Команда форума
Crazy

Конечно гониво.. это надо работать в 2раза больше..
а если еще и безжалостно рефакторить... то на пиво
времени не останется.. :)
 

syfisher

TDD infected!!
Маленькая цитатка. Я, кажется, ее уже где-то приводил:

http://www.sitepoint.com/forums/showpost.php?p=1720981&postcount=33

Если по английски научился понимать, то поймешь, про что разговор. Но, как правильно выразился admin, до этого нужно еще дорасти...
 

sergeiklein

Guest
syfisher возможно не дорос :) Я просто пердлложил несколько подход. Я понмаю что тест можно написать и быть уверенным что именно в этом случаее все будет работать, но практика отличается от того что написано например по этой ссылке которая ввыше. И тест выглядит так что не всякий сядет его разбирать. Потому как тест за собой тянет не простейшие типы. Мой подход в трасеровке - каждая функция при выполнении отчитывается за себя. Пока себя оправдывает.
 
Crazy

Crazy

Developer
Автор оригинала: sergeiklein
И тест выглядит так что не всякий сядет его разбирать.
Нажмите для раскрытия...
Никто не заставляет тебя писать такие плохие тесты. Пиши хорошие тесты.

Потому как тест за собой тянет не простейшие типы.
Нажмите для раскрытия...
Что это за загадочная связь между тестами и простотой типов?

Мой подход в трасеровке - каждая функция при выполнении отчитывается за себя.
Нажмите для раскрытия...
А нельзя ли осведомиться, что это за новое слово в технологии разработки -- трасеровка (ну или трассировка, если ты имел в виду это слово)? Также интересует, что понимается под загадочным процессом "отчитываться за себя при выполнении".

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

sergeiklein

Guest
Crazy я не понимаю, тебе дейсвительно интересно или просто стеб. Хочешь говорить говори по человчески. ок.

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

Простой пример:

Trace::Message('ClassName::FunctionName::Fatal',$_iFatalVariable);

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

Масив выводится в конце выпонения, например под сформированной страницей. Как сделать все это удобней думайте.

Извеняюсь за жаргон, очипятки и орфографию :)
 
Crazy

Crazy

Developer
sergeiklein, JFYI: по-русски это называется протоколированием. Вот только к тестированию это не имеет никакого отношения -- это технология отладки.

Чем отладка отличается от тестирования -- нужно объяснять?
 
pachanga

pachanga

Новичок
М-да, sergeiklein, я вот порой думаю, что по молодости всякой глупости наговорил в форумах разных, но они, к счастью, в большинстве своем умерли да и не было тогда еще google cache...

А вот тебе еще предстоит перечитать себя лет так через 5 и про "гониво" и про особливый "подход в трасеровке " :)
 

sergeiklein

Guest
Crazy объясни неразумному. серьезно. только наврядли это в этом топе оставят.
 
Crazy

Crazy

Developer
Объясняю:

1. Тестирование проводят для того, чтобы убедиться, что программа удовлетворяет требованиям. На выходе процедуры тестирования есть два исходна: "Да, удовлетворяет" и "Нет, нарушает следующие требования...."

Одна из технологий тестирования -- юнит-тестирование.

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

Одна из технологий отладки -- протоколирование. Состоит в тем, что отлаживаемая программа пишет в протокол информацию о своем выполнении.
 
Дмитрий Попов

Дмитрий Попов

сторож
*офф*, почему как только sergeiklein отмечается в какой-нибудь интересной теме в разделе "для продвинутых", тема сразу становится помоешной?
 

sergeiklein

Guest
Crazy спасибо. Не совсем понятно было тестироваие в этом варианте, если этот подход тестирования тестирует работоспособность кода, то подход прецедентов тестирует логику. Прецендеты, актеры, отношения - см. UML.

Подход в целом разумен, занимает не так много времени если тестировать больше классы(компоненты, модули). В чем-то пожож на подход ООП, где стоит, а где не стоит зависит от задачи.

Для таких как я, которые не понимают разумности подхода :)
http://www.xprogramming.ru/Articles/LoveUT.html

Цитата "UI - это особый случай. Существуют технологии, позволяющие выполнить юнит тест прямо на уровне экрана, клавиатуры и мыши, но они обычно неудобны. Мы советуем разрабатывать тонкий уровень UI с хорошо определенными интерфейсами к остальной части приложения. Тестируйте юнит тестами вплоть до этого уровня и оставьте GUI для тестировщиков."

Дмитрий Попов некоторые люди слишком зносчивы чтобы стерпеть какое либо мнение кроме своего.
 
Войдите или зарегистрируйтесь для ответа.
Сверху