Стандартный тест памяти .Net TDD

Question

Полезно ли писать стандартизированный метод TDD [Test], который выявил бы общие проблемы с памятью?

Набор тестов можно было бы легко и быстро применить к методу, и он мог бы решить «классические» проблемы с памятью .NET, но при этом «перебил бы» классические решения.

Например, распространенными проблемами с памятью могут быть: слишком большое перемещение сборщиком мусора ; выделяя слишком много; слишком много сборщиков мусора (классический пример предпочитает StringBuilder вместо строковых reallocs); слишком долго удерживать память (классический пример вызова dispose и не использовать финализаторы); объекты не по назначению достигают g1, g2, LOH; небольшие утечки, которые со временем приводят к чему-то значительному ... и другим.

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

[Test]
public void Verify_MyMethodUnderTest_Is_Unlikely_To_Have_Common_Memory_Problem()
{

//-Setup
var ExpectationToleranceA = ...
var ExpectationToleranceB = ...
...

//-Execute
var MeasurementA = MyClassUnderTest.MyMethodUnderTest( dependancyA ) ; 
var MeasurementB = MyClassUnderTest.MyMethodUnderTest( dependancyB ) ; 
…

//-Verfiy
Assert.That(  MeasurementA  , Is.WithinTolerance( ExpectationToleranceA  ) ) ;
Assert.That(  MeasurementB  , Is.WithinTolerance( ExpectationToleranceB  ) ) ;

}

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

есть ли у этой идеи ноги?

Здесь есть связанный вопрос для приложения C ++, Обнаружение утечки памяти при выполнении модульных тестов , что является аналогичным вопросом, но не совсем тем же. Вопрос Твка состоит в том, чтобы смотреть на память после того, как все тесты были выполнены ...

Моя идея здесь для .NET 1) модульное тестирование каждого метода на общие проблемы с памятью 2) сбой классических проблем с памятью 3) передать классические исправления в классические проблемы с памятью 4) быть в состоянии быстро бросить быстрый стандартный тест на функцию, чтобы увидеть, проявляет ли она классические симптомы 5) уметь обновлять стандартное тестирование давления памяти TDD .Net, применяемое в модульном тесте. Это подразумевает рефакторинг вышеприведенного кода, так что при обновлении до стандартного теста будут обновляться тесты памяти, применяемые во всем наборе тестов Nunit для проекта.

(p.s. Я знаю, что нет вызова Is.WithinTolerance, но я просто демонстрировал идею.) ура ...

Answer 1

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

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

Поэтому я бы посоветовал провести интеграционное тестирование в нескольких штатах. Протестируйте систему под разными уровнями нагрузки и посмотрите, какие проблемы с памятью возникают (если есть). Этот вид тестирования будет гораздо более полезным для вас.

Answer 2

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

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

Если вы хотите сделать что-то подобное, подумайте о вызове метода GC.Collect () до и после операции, которую вы хотите протестировать. Сделайте несколько вызовов подряд, чтобы легче ощутить рост потребления памяти. Попробуйте добавить такие тесты в отдельную сборку за ночь (отдельно от реальных модульных тестов), поскольку это может занять много времени. Запустите тесты на отдельной машине, где у вас есть полный контроль (открытый браузер с некоторой флэш-анимацией или антивирусный сканер во время тестов могут испортить ваши результаты). Храните цифры для потребления памяти где-то для последующего просмотра. Это заставит вас осознать медленное увеличение потребления памяти во время длительных циклов разработки.

Answer 3

Я бы сказал, что это плохая идея. Если вы хотите написать тесты, которые «проверяют» некоторое поведение, скажем, сборщика мусора, вы в основном «тестируете» код, который вы не можете контролировать. Точное поведение сборщика мусора является деталью реализации текущего CLR. Это может измениться в будущем, в результате чего ваши тесты «провалится» В большинстве случаев вы, вероятно, не сможете ничего изменить в своем коде, чтобы «исправить» тесты, поэтому вы вынуждены изменить тесты, чтобы отразить новую реализацию. На мой взгляд, это ограниченное использование.

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

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

Только мои 5 центов.