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

[sergeiklein]

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

 

[Crazy]

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

 

[sergeiklein]

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

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

 

[confguru]

sergeiklein

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

 

[Crazy]

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

 

[confguru]

Crazy

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

 

[Crazy]

Вот! sergeiklein, никогда не используй юнит-тесты.

 

[sergeiklein]

молодцы...

 

[syfisher]

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

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

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

 

[sergeiklein]

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

 

[Crazy]

Автор оригинала: sergeiklein
И тест выглядит так что не всякий сядет его разбирать.

Никто не заставляет тебя писать такие плохие тесты. Пиши хорошие тесты.

Потому как тест за собой тянет не простейшие типы.

Что это за загадочная связь между тестами и простотой типов?

Мой подход в трасеровке - каждая функция при выполнении отчитывается за себя.

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

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

 

[sergeiklein]

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

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

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

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

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

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

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

 

[Crazy]

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

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

 

[pachanga]

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

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

 

[sergeiklein]

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

 

[Crazy]

Объясняю:

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

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

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

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

 

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

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

 

[sergeiklein]

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

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

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

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

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

 

[Crazy]

Автор оригинала: sergeiklein
В чем-то пожож на подход ООП, где стоит, а где не стоит зависит от задачи.

Ты продолжаешь бредить.

 

[sergeiklein]

Автор оригинала: Crazy
Ты продолжаешь бредить.

Возможно. Я вижу здесь собралися определный контенгент.