Сообщение Re[3]: Юнит тестирование "памяти" от 23.04.2015 6:00
Изменено 23.04.2015 6:01 Nikita Lyapin
Здравствуйте, fedor.reznik, Вы писали:
S>>Под debug он проходит, а под релизом сразу падает. Что естественно b1 и b2 — не используются в коде.
S>>Не совсем очевидный нюанс при таком подходе: у нас появляется зависимость от конфигурации билда.
FR>Вообще говоря, профилировать имеет смысл только Release версии. Хотя ваш пример несколько искусственный и в реальности таких засад будет меньше, но тем не менее.
Возможно два варианта: 1. Мы пишем юнит тесты на каждый класс. 2. Мы пишем что-то вроде нагрузочных тестов на сценарии и смотрим чтобы в этом сценарии память расходовалась в приемлемых объемах.
Плюсы первого подхода: а) можно быстро понять что конкретно сломалось; б) быстрые.
Минусы первого подхода: а) зависят от внутреннего дизайна кода — в случае рефакторинга нужно будем менять кучу тестов. б) банально больше строк кода с тестами в сравнении со вторым подходом.
Плюсы второго подхода: а) т.к. привязаны к сценариям, любой член команды может понять что сломалось (тестер, менеджер и т.п.; особенно если это реализовано с помощью Specflow). Все понимают, что допустим в сценарии "Создание резервной копии структуры библиотеки" в этой версии софта расходуется память; б) кода самих тестов заметно меньше; в) нет зависимости от внутренней организации кода — нам абсолютно без разницы какие классы и с кем взаимодействуют, где и в каком классе теперь хранятся данные, главное чтобы сценарий в целом не расходовал память. Т.е. в случае рефакторинга тесты не переписываются; г)
Минусы второго подхода: а) Разработчику нужно отлаживаться, чтобы понять что именно привело к падению теста; б) медленные.
Вы сейчас реализовали поддержку первого подхода. Лично мне кажется, что тестирование (а точнее, наверное, профилирование) памяти лучше ложится на второй подход. Причем мне видится так: ставим через инсталятор на виртуальную машину серверную часть, аналогично клиентскую часть. Прогоняем через CodedUI сценарий и смотрим что с памятью. Вот если бы dotMemory выступал как сервис: в какой-то момент указываешь процесс, в какой-то момент получаешь результат.
Разве Вам (JetBrains) не проще реализовать такой функционал, чем делать библиотеку для Unit тестирования? ИМХО такой подход найдет не мало своих сторонников.
S>>Под debug он проходит, а под релизом сразу падает. Что естественно b1 и b2 — не используются в коде.
S>>Не совсем очевидный нюанс при таком подходе: у нас появляется зависимость от конфигурации билда.
FR>Вообще говоря, профилировать имеет смысл только Release версии. Хотя ваш пример несколько искусственный и в реальности таких засад будет меньше, но тем не менее.
Возможно два варианта: 1. Мы пишем юнит тесты на каждый класс. 2. Мы пишем что-то вроде нагрузочных тестов на сценарии и смотрим чтобы в этом сценарии память расходовалась в приемлемых объемах.
Плюсы первого подхода: а) можно быстро понять что конкретно сломалось; б) быстрые.
Минусы первого подхода: а) зависят от внутреннего дизайна кода — в случае рефакторинга нужно будем менять кучу тестов. б) банально больше строк кода с тестами в сравнении со вторым подходом.
Плюсы второго подхода: а) т.к. привязаны к сценариям, любой член команды может понять что сломалось (тестер, менеджер и т.п.; особенно если это реализовано с помощью Specflow). Все понимают, что допустим в сценарии "Создание резервной копии структуры библиотеки" в этой версии софта расходуется память; б) кода самих тестов заметно меньше; в) нет зависимости от внутренней организации кода — нам абсолютно без разницы какие классы и с кем взаимодействуют, где и в каком классе теперь хранятся данные, главное чтобы сценарий в целом не расходовал память. Т.е. в случае рефакторинга тесты не переписываются; г)
Минусы второго подхода: а) Разработчику нужно отлаживаться, чтобы понять что именно привело к падению теста; б) медленные.
Вы сейчас реализовали поддержку первого подхода. Лично мне кажется, что тестирование (а точнее, наверное, профилирование) памяти лучше ложится на второй подход. Причем мне видится так: ставим через инсталятор на виртуальную машину серверную часть, аналогично клиентскую часть. Прогоняем через CodedUI сценарий и смотрим что с памятью. Вот если бы dotMemory выступал как сервис: в какой-то момент указываешь процесс, в какой-то момент получаешь результат.
Разве Вам (JetBrains) не проще реализовать такой функционал, чем делать библиотеку для Unit тестирования? ИМХО такой подход найдет не мало своих сторонников.
Re[3]: Юнит тестирование "памяти"
Здравствуйте, fedor.reznik, Вы писали:
S>>Под debug он проходит, а под релизом сразу падает. Что естественно b1 и b2 — не используются в коде.
S>>Не совсем очевидный нюанс при таком подходе: у нас появляется зависимость от конфигурации билда.
FR>Вообще говоря, профилировать имеет смысл только Release версии. Хотя ваш пример несколько искусственный и в реальности таких засад будет меньше, но тем не менее.
Возможно два варианта:
1. Мы пишем юнит тесты на каждый класс.
2. Мы пишем что-то вроде нагрузочных тестов на сценарии и смотрим чтобы в этом сценарии память расходовалась в приемлемых объемах.
Плюсы первого подхода:
а) можно быстро понять что конкретно сломалось; б) быстрые.
Минусы первого подхода:
а) зависят от внутреннего дизайна кода — в случае рефакторинга нужно будем менять кучу тестов. б) банально больше строк кода с тестами в сравнении со вторым подходом.
Плюсы второго подхода:
а) т.к. привязаны к сценариям, любой член команды может понять что сломалось (тестер, менеджер и т.п.; особенно если это реализовано с помощью Specflow). Все понимают, что допустим в сценарии "Создание резервной копии структуры библиотеки" в этой версии софта расходуется память; б) кода самих тестов заметно меньше; в) нет зависимости от внутренней организации кода — нам абсолютно без разницы какие классы и с кем взаимодействуют, где и в каком классе теперь хранятся данные, главное чтобы сценарий в целом не расходовал память. Т.е. в случае рефакторинга тесты не переписываются; г)
Минусы второго подхода:
а) Разработчику нужно отлаживаться, чтобы понять что именно привело к падению теста; б) медленные.
Вы сейчас реализовали поддержку первого подхода. Лично мне кажется, что тестирование (а точнее, наверное, профилирование) памяти лучше ложится на второй подход. Причем мне видится так: ставим через инсталятор на виртуальную машину серверную часть, аналогично клиентскую часть. Прогоняем через CodedUI сценарий и смотрим что с памятью. Вот если бы dotMemory выступал как сервис: в какой-то момент указываешь процесс, в какой-то момент получаешь результат.
Разве Вам (JetBrains) не проще реализовать такой функционал, чем делать библиотеку для Unit тестирования? ИМХО такой подход найдет не мало своих сторонников.
S>>Под debug он проходит, а под релизом сразу падает. Что естественно b1 и b2 — не используются в коде.
S>>Не совсем очевидный нюанс при таком подходе: у нас появляется зависимость от конфигурации билда.
FR>Вообще говоря, профилировать имеет смысл только Release версии. Хотя ваш пример несколько искусственный и в реальности таких засад будет меньше, но тем не менее.
Возможно два варианта:
1. Мы пишем юнит тесты на каждый класс.
2. Мы пишем что-то вроде нагрузочных тестов на сценарии и смотрим чтобы в этом сценарии память расходовалась в приемлемых объемах.
Плюсы первого подхода:
а) можно быстро понять что конкретно сломалось; б) быстрые.
Минусы первого подхода:
а) зависят от внутреннего дизайна кода — в случае рефакторинга нужно будем менять кучу тестов. б) банально больше строк кода с тестами в сравнении со вторым подходом.
Плюсы второго подхода:
а) т.к. привязаны к сценариям, любой член команды может понять что сломалось (тестер, менеджер и т.п.; особенно если это реализовано с помощью Specflow). Все понимают, что допустим в сценарии "Создание резервной копии структуры библиотеки" в этой версии софта расходуется память; б) кода самих тестов заметно меньше; в) нет зависимости от внутренней организации кода — нам абсолютно без разницы какие классы и с кем взаимодействуют, где и в каком классе теперь хранятся данные, главное чтобы сценарий в целом не расходовал память. Т.е. в случае рефакторинга тесты не переписываются; г)
Минусы второго подхода:
а) Разработчику нужно отлаживаться, чтобы понять что именно привело к падению теста; б) медленные.
Вы сейчас реализовали поддержку первого подхода. Лично мне кажется, что тестирование (а точнее, наверное, профилирование) памяти лучше ложится на второй подход. Причем мне видится так: ставим через инсталятор на виртуальную машину серверную часть, аналогично клиентскую часть. Прогоняем через CodedUI сценарий и смотрим что с памятью. Вот если бы dotMemory выступал как сервис: в какой-то момент указываешь процесс, в какой-то момент получаешь результат.
Разве Вам (JetBrains) не проще реализовать такой функционал, чем делать библиотеку для Unit тестирования? ИМХО такой подход найдет не мало своих сторонников.