А как вы тестируете свои шедевры?

← →
Mystic © (2008-01-23 19:20) [40]

> Sandman25 (23.01.08 15:58) [32]
>
> 3. LOG.debug(...)

LOG.debug(...) помогает исправить ошибку. Но для этого ее еще надо найти :)

← →
Mystic © (2008-01-23 19:21) [41]

Т. е. обнаружить. А при помощи LOG.debug() ты находишь саму ошибку в коде и исправляешь.

← →
Kolan © (2008-01-23 19:24) [42]

>
> Процедура обработки исключений выглядит как обработчик события
> Application.OnException

А имя процедуры не отправляется например?

← →
@!!ex © (2008-01-23 19:27) [43]

> Нужно тестировать не проект вцелом, а "кубики" из которых
> проект сделан...
> В папке с проектом имеем папку TEST с набором тестовых приложений
> для тестирования "кубиков"

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

← →
Kenny (2008-01-23 19:42) [44]

> тесты - это скорее из рода фантастики

У кого как.. )

← →
Псалтырь (2008-01-23 21:10) [45]

eurekalog.com

← →
iZEN © (2008-01-23 23:13) [46]

> Галинка © (23.01.08 14:43) [24]
>
> Про исключения. Тестится программа не на такие ошибки. А
> на ошибки логики сорее. Или на просчеты. По ним исключения
> не выдаются, но программа работает не так как хотелось бы.
> Вот и хочется посмотреть, что же мы там имеем.

В простейшем случае:
System.out.println("Случилась бяка: " + msg);
(работает везде)

В других случаях:
1) Assert"s
2) JUnit Case
3) Java Platform Debugger Architecture (JPDA)

← →
Игорь Шевченко © (2008-01-23 23:14) [47]

> А имя процедуры не отправляется например?

Всенепременно отправляется. Весь стек вызовов, который доступен.

← →
Галинка © (2008-01-23 23:42) [48]

всем. Я теперь ужо недели три как опять приземлилась на шарпе. Опять разукрашиваю. Только теперь текст. Вот и надо смотреть, в правильные ли места записались символы форматирования.

@!!ex © (23.01.08 19:27) [43]

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

И проблема всегда остается - видишь не то, что накодено, а то, что хотелось бы видеть. Никогда не забуду, как два дня билась над SQL-запросом, а потом оказалось, что я двоеточее там где-то забыла. ((( И не увидишь это сразу (((

← →
MsGuns © (2008-01-24 09:26) [49]

>data © (23.01.08 17:16) [36]
>и отдел тестирования стоит напрячь

Да че там мелочиться с отделом - можно сразу напрячь всю корпорацию тестирования ;)

← →
Sandman25 (2008-01-24 11:21) [50]

Mystic © (23.01.08 19:20) [40]

У меня LOG.debug ставится не тогда, когда надо найти ошибку, а почти после каждой строчки. Так что по логам можно узнать и значения переменных, и путь выполнения программы (в какой ветке if был, сколько раз выполнился while) и т.д.
Так что по такому логу искать ошибку одно удовольствие.

← →
Sandman25 (2008-01-24 11:23) [51]

Mystic © (23.01.08 19:21) [41]

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

← →
Asker (2008-01-24 15:09) [52]

unit-тесты это инструмент разработчика, а не тестера
иначе уверенности в работоспособности нету никакой
непроверенный код - это нерабочий код - один из утверждений юнит-тестирования)

← →
iZEN (2008-01-24 16:00) [53]

> Asker (24.01.08 15:09) [52]
>
> unit-тесты это инструмент разработчика, а не тестера
> иначе уверенности в работоспособности нету никакой
> непроверенный код - это нерабочий код - один из утверждений
> юнит-тестирования)

Вопрос о качестве покрытия кода unit-тестами у вас не стоит?
Как вы определяете, нужно ли писать unit-тест или нет? (принцип: "сначала пишется тест" часто ли вы соблюдаете?)

← →
Asker (2008-01-24 17:30) [54]

iZEN (24.01.08 16:00) [53]
есть же утилиты проверяющие покрытие кода, а код для которого нужно писать тесты или нет непростой, обычно нужно писать для всего кроме того для чего уже писались тесты в прошлом(сходные операции) и стало быть в работоспособности нету сомнений

← →
Марсер © (2008-01-24 21:50) [55]

> data © (23.01.08 17:16) [36]
>
>
> > В основном интересует ситуация, если ошибка/баг вылазит
> > не все время
>
> логи, и отдел тестирования стоит напрячь

Господи, и живут же люди! :-(

← →
Марсер © (2008-01-24 21:50) [56]

← →
Mystic © (2008-01-29 12:42) [57]

> У меня LOG.debug ставится не тогда, когда надо найти ошибку,
> а почти после каждой строчки. Так что по логам можно узнать
> и значения переменных, и путь выполнения программы (в какой
> ветке if был, сколько раз выполнился while) и т.д.
> Так что по такому логу искать ошибку одно удовольствие.

Вспоминаю один свой проект: восстановление трехмерной поверхности по результатам интерференции в белом свете . Там анализировалось и обрабатывалось ~50-200 Mb информации. Мысленно представил себе лог, который протоколирует каждое действие... Вряд ли бы я дождался бы окончание логирования...

← →
Sandman25 (2008-01-29 13:20) [58]

Mystic © (29.01.08 12:42) [57]

if (LOG.isDebugEnabled()){ for (...){ LOG.debug(..); ... } } else for (...){ ... }

← →
Mystic © (2008-01-29 14:44) [59]

> Sandman25 (29.01.08 13:20) [58]

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

Обычно процесс шел таким образом: выполняем некоторый шаг в MATAB. Потом строим по промежуточным данным всякие графики. Берем сомнительные места. Прогоняем на них все наши вычисления еще раз. И т. д. и т. п.

← →
Галинка © (2008-01-29 14:53) [60]

Mystic © (29.01.08 14:44) [59]

вообще-то это больше похоже на выверку мат.модели, а не на анализ работы программы.

← →
Sandman25 (2008-01-29 15:23) [61]

Mystic © (29.01.08 14:44) [59]

Никто не заставляет писать миллион шагов. В каждом классе свой логгер, а в конфигурационных файлах прописано, какие логгеры какую информацию выводят, причем настройки иерархические. Например, все логгеры из пакета (и вложенных пакетов) com.foo.bar работают в режиме INFO, логгер com.foo.bar.dog работает в режиме DEBUG, остальные логгеры работают в режиме ERROR. То есть можно динамически включать только те сообщения, которые нужны.

← →
Mystic © (2008-01-29 15:24) [62]

> Sandman25 (29.01.08 15:23) [61]

Не помогает это никак :) Потому что я должен логировать все, потому что я не знаю, что меня заинтересует при последующем просмотре. Т. е. я не знаю заранее, какой шаг из миллиона меня заинтересует.

Например, разрешение камеры 400 x 1600, я делаю попиксельную обработку 800 фреймов. Соответственно или лог будет на каждый пиксел, либо его вообще не будет. Либо мне прийдется заранее вычислить интересные точки

if (IsInterestPoint(x, y)) log(something);

что тоже не очень удачно, потому что интерес к точке (x, y) может породить интерес к точке (x1, y1), для этого надо будет еще раз запускать всю программу и т. п. Да и построить графики по результатам надо будет в каком-то другом приложении...

← →
Sandman25 (2008-01-29 16:11) [64]

Mystic © (29.01.08 15:38) [63]

То есть грубо говоря, приходит случайный невоспроизводимый набор данных, интересно буквально всё, но записывать всё не хочется? Тогда, конечно, наука бессильна :)

> Тогда, конечно, наука бессильна :)

Почему бессильна? Тут рулит MATLAB :) Вообще спасет любая интерпретация, когда нет никаких проблем в отладке выполнить еще парочку операторов, построить график и т. п. Другой вариант --- самому писать аналогичную консоль.

← →
Sandman25 (2008-01-29 17:09) [66]

Mystic © (29.01.08 17:04) [65]

Это называется отладка: приостановил выполнение, посмотрел переменные, изменил их значение, продолжил...

> Это называется отладка: приостановил выполнение, посмотрел
> переменные, изменил их значение, продолжил...

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

> собсно сабж. В основном интересует ситуация, если ошибка/баг
> вылазит не все время (т.е. при трассировке то вылазит, то
> нет).

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

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

← →
Sandman25 (2008-01-30 08:42) [69]

Mystic © (29.01.08 20:11) [67]

То есть всё упирается в экспорт. Если есть экспорт, с данными можно делать всё, что угодно.

> Sandman25 (30.01.08 08:42) [69]

Я уже писал: в данном случае мне очень помогал MATLAB: отлаживаешь/составляешь алгоритм в нем, а потом просто в C++ добиваешься идентичной работы уже имея промежуточные результаты. Как вариант можно использовать отладочную консоль, где бы можно было во время работы программы экспортнуть нужный вектор.

В общем общей панацеи, которая бы работала во всех случаях, нет. С другой стороны мне рассказывали об одном человеке, который обходился вообще без отладки. Программу на C++ набирал в Far. Потом долго смотрел на нее. Считал, что если в программе остались синтаксические ошибки, то наверняка в ней есть и семантические. Как только изучение исходного текста проходило его требовательный взгляд, программа компилировалась (без ошибок компиляции) и баги в ней были очень редки :)

А как вы тестируете свои шедевры? Найти похожие ветки