про тесты, желательно попроще и попонятней — язык русский-англ.
спасибо.

Здравствуйте, Аноним, Вы писали:

А>про тесты, желательно попроще и попонятней — язык русский-англ.
А>спасибо.
Не надо мне статейку... я сам разбирусь...

Здравствуйте, Tom, Вы писали:

Tom>Посмотри на typemock.net, он позволит тебе прозрачно для твоего кода, тоесть не меняя его вообще изолировать от внешней среды.
Tom>На самом деле их решение является для рынка революционным и пока я не видел аналогов.
Хорошо, посмотрю, спасибо...
А вот еще скажите в плане юнит тестирования лучше NUnit или можно обойтись штатными средствами VS Team Edition? Я так смотрю даже EntLib написана с использованием NUnit. (хотя и недочетов там есть определенное колличество.... )

Здравствуйте, Ellin, Вы писали:

E>А вот еще скажите в плане юнит тестирования лучше NUnit или можно обойтись штатными средствами VS Team Edition? Я так смотрю даже EntLib написана с использованием NUnit. (хотя и недочетов там есть определенное колличество.... )

Мне NUnit нравится. Он кстати очень удобно интегрируется в студию с помощью ReSharper'а.

Здравствуйте, Ellin, Вы писали:

E>Здравствуйте, Аноним, Вы писали:

А>>про тесты, желательно попроще и попонятней — язык русский-англ.
А>>спасибо.
E>Не надо мне статейку... я сам разбирусь...
рад за вас — а вот я бы не отказался

Здравствуйте, Ellin, Вы писали:

E>А вот еще скажите в плане юнит тестирования лучше NUnit или можно обойтись штатными средствами VS Team Edition? Я так смотрю даже EntLib написана с использованием NUnit. (хотя и недочетов там есть определенное колличество.... )

Только не встроенная тулза!!! Много раз пожалели что с ней связались. NUnit однозначно лучше. Но можно так же глянуть в сторону MbUnit

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Ellin, Вы писали:

E>>А вот еще скажите в плане юнит тестирования лучше NUnit или можно обойтись штатными средствами VS Team Edition? Я так смотрю даже EntLib написана с использованием NUnit. (хотя и недочетов там есть определенное колличество.... )

S>Только не встроенная тулза!!! Много раз пожалели что с ней связались. NUnit однозначно лучше. Но можно так же глянуть в сторону MbUnit
А почему встроенная тулза плохая? Лично я вчера никак не мог понять, почему он не перебилдевает мои сборки при прогоне тестов... т.е. тесты постоянно валились, хотя я баги исправил...

Здравствуйте, Аноним, Вы писали:

А>>>про тесты, желательно попроще и попонятней — язык русский-англ.
А>рад за вас — а вот я бы не отказался

Если с английским все в порядке, то вот есть книжка:
Pragmatic Unit Testing with C#

Здравствуйте, MozgC, Вы писали:
MC>Если с английским все в порядке, то вот есть книжка:
MC>Pragmatic Unit Testing with C#

спасибо.

Здравствуйте, Ellin, Вы писали:

E>Здравствуйте, samius, Вы писали:

S>>Только не встроенная тулза!!! Много раз пожалели что с ней связались. NUnit однозначно лучше. Но можно так же глянуть в сторону MbUnit
E>А почему встроенная тулза плохая? Лично я вчера никак не мог понять, почему он не перебилдевает мои сборки при прогоне тестов... т.е. тесты постоянно валились, хотя я баги исправил...

Во-первых, встроенная тулза ОЧЕНЬ долгая. На нескольких тысячах тестов разница заметна на глаз.
Во-вторых, у встроенной тулзы большие проблемы с иерархиями тестов.
В-третьих, у встроенной тулзы возможен разный порядок выполнения тестов, оттого инициализация и деинициализация Fixture производится как-попало. Если в NUnit-е фактически есть гарантия того, что все тесты одного Fixture выполняются подряд между [FixtureSetUp] и [FixtureTearDown], то во встроенной тулзе между этими методами могут быть вызваны другие тесты от других Fixture. Фактически они гарантируют только то, что каждый тест выполнится между своими методами инициализации и деинициализации. Отсюда сложности с Arrange + Act + Assert подходом к тестированию; сложности с тем, чтобы скажем в методе инициализации FixtureSetUp открыть транзакцию, прогнать несколько тестов и потом в FixtureTearDown откатить транзакцию, потому как между открытием транзакции и закрытием могут попасть тесты из других классов, которые будут выполняться в своей транзакции.
В четвертых, встроенная тулза не производит реюз класса для сценария с несколькими тестами. Для каждого теста класс теста создается заново. Это тоже приводит к некоторым проблемам. Для того, чтобы сохранить общее для нескольких тестов состояние, приходится использовать статические переменные. Время жизни таких переменных не определено, т.к. FixtureTearDown метод вызовется когда-нибудь, а не сразу по завершению всех тестов данного класса.

Не исключаю, что я не умею правильно готовить эту тулзу, но проблем от нее видал предостаточно.

Здравствуйте, samius, Вы писали:

S>>>Только не встроенная тулза!!! Много раз пожалели что с ней связались. NUnit однозначно лучше. Но можно так же глянуть в сторону MbUnit
E>>А почему встроенная тулза плохая? Лично я вчера никак не мог понять, почему он не перебилдевает мои сборки при прогоне тестов... т.е. тесты постоянно валились, хотя я баги исправил...

S>Во-первых, встроенная тулза ОЧЕНЬ долгая. На нескольких тысячах тестов разница заметна на глаз.

Да, есть такое западло :о)

S>Во-вторых, у встроенной тулзы большие проблемы с иерархиями тестов.

Что значит "иерархии тестов" и какие проблемы?

S>В-третьих, у встроенной тулзы возможен разный порядок выполнения тестов, …

Да, это, я так понял, by design. а разве плох сам подход, заключающийся в том, что каждый тест должен быть изолирован от других? Зачем нужно поддерживать связанность между тестами?

S>В четвертых, встроенная тулза не производит реюз класса для сценария с несколькими тестами. Для каждого теста класс теста создается заново.

Ты про работу визарда? Я тесты все руками набираю, как хочу, так и организовываю.

S>Не исключаю, что я не умею правильно готовить эту тулзу, но проблем от нее видал предостаточно.

Да я тоже не большой специалист, так, балуюсь, но — удобно. Можно посмотреть, какие строки не покрыты и другие подобные прелести чуда "из коробки" весьма вдохновляют. Конечно, оно не так заточено как NUnit, но в чём-то подкупает.

Здравствуйте, _FRED_, Вы писали:
_FR>Да я тоже не большой специалист, так, балуюсь, но — удобно. Можно посмотреть, какие строки не покрыты и другие подобные прелести чуда "из коробки" весьма вдохновляют. Конечно, оно не так заточено как NUnit, но в чём-то подкупает.
Как это?

S>Во-первых, встроенная тулза ОЧЕНЬ долгая. На нескольких тысячах тестов разница заметна на глаз.
S>Во-вторых, у встроенной тулзы большие проблемы с иерархиями тестов.
А что такое иерархия тестов?

S>В-третьих, у встроенной тулзы возможен разный порядок выполнения тестов, оттого инициализация и деинициализация Fixture производится как-попало. Если в NUnit-е фактически есть гарантия того, что все тесты одного Fixture выполняются подряд между [FixtureSetUp] и [FixtureTearDown], то во встроенной тулзе между этими методами могут быть вызваны другие тесты от других Fixture.
Разный порядок выполнения — это нормально и даже плюс. Тесты по определению должны быть независимые друг от друга.

S>В четвертых, встроенная тулза не производит реюз класса для сценария с несколькими тестами. Для каждого теста класс теста создается заново.
Это не проблема, это нормально

Здравствуйте, Ellin, Вы писали:

E>Здравствуйте, Tom, Вы писали:

Tom>>Посмотри на typemock.net, он позволит тебе прозрачно для твоего кода, тоесть не меняя его вообще изолировать от внешней среды.
Tom>>На самом деле их решение является для рынка революционным и пока я не видел аналогов.
E>Хорошо, посмотрю, спасибо...
E>А вот еще скажите в плане юнит тестирования лучше NUnit или можно обойтись штатными средствами VS Team Edition? Я так смотрю даже EntLib написана с использованием NUnit. (хотя и недочетов там есть определенное колличество.... )

Лично нам (моей компании и мне лично) ничего кроме студии и typemock для работы с тестами не надо.
В принципе всё устраивает.

Здравствуйте, Ellin, Вы писали:

E>Здравствуйте, _FRED_, Вы писали:
_FR>>Да я тоже не большой специалист, так, балуюсь, но — удобно. Можно посмотреть, какие строки не покрыты и другие подобные прелести чуда "из коробки" весьма вдохновляют. Конечно, оно не так заточено как NUnit, но в чём-то подкупает.
E>Как это?
При выполнении тестов студия записывает какие строки кода выполнялись. Называется это code coverage. Очень удобно для того что бы понимать какой процент кода покрыт тестами, какие test case-ы надо реалитзовать итп...

Здравствуйте, Ellin, Вы писали:

E>Здравствуйте, _FRED_, Вы писали:
_FR>>Да я тоже не большой специалист, так, балуюсь, но — удобно. Можно посмотреть, какие строки не покрыты и другие подобные прелести чуда "из коробки" весьма вдохновляют. Конечно, оно не так заточено как NUnit, но в чём-то подкупает.
E>Как это?

В окне Test Results правой кнопкой на тесте, выбираешь Code Coverage Results, там встаёшь на методе, правой кнопкой, Go to source code. Покажется source code, различные регионы которого закрашемы различными цветами. Легенда цветов — Tools\Options\Environment\Fonts and Colors: "Coverage Not Touched Area", "Coverage Partially Touched Area", "Coverage Touched Area".

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

S>>Во-вторых, у встроенной тулзы большие проблемы с иерархиями тестов.

_FR>Что значит "иерархии тестов" и какие проблемы?
Допустим, есть несколько реализаций некоторого интерфейса. И есть общие тесты для этих реализаций. В NUnit я могу создать базовый класс с N тестами, определить в нем виртуальный фабричный метод, создать несколько производных классов, перекрыть в них метод создания экземпляра и таким образом получу N*M тестов, где M кол-во производных классов с тестами. С vsts такой трюк не прокатывает. Приходится копипастить.


S>>В-третьих, у встроенной тулзы возможен разный порядок выполнения тестов, …

_FR>Да, это, я так понял, by design. а разве плох сам подход, заключающийся в том, что каждый тест должен быть изолирован от других? Зачем нужно поддерживать связанность между тестами?
Это немного другая связность. В методах FixtureSetUp и FixtureTearDown и их аналогах в vsts принято производить инициализацию общую для всех тестов Fixture. Беда в том, что Test1.FixtureSetUp и Test2.FixtureSetUp могут использовать общие ресурсы типа глобальных состояний, или БД (не кидайте камни, знаю что глобальные состояния зло, просто пример привел).
Так вот, допустим FixtureSetUp метод кладет что-то в БД, а FixtureTearDown производит очистку из БД. А теперь представим следующий сценарий

vsts:

F1.FixtureSetUp();
F1.Test1();
F2.FixtureSetUp();
F2.Test1();
F1.Test2(); <---- этот тест видит в БД совсем не те данные, что ждет.
F1.FixtureTearDown();
F2.FixtureTearDown();

в NUnit-е такой сценарий невозможен.

Я понимаю, всю инициализацию и деинициализацию таких тестов можно положить в SetUp и TearDown методы. Однако, когда тестов тысячи, то очень хочется сэкономить и использовать общую инициализацию, особенно в случае с БД.

S>>В четвертых, встроенная тулза не производит реюз класса для сценария с несколькими тестами. Для каждого теста класс теста создается заново.

_FR>Ты про работу визарда? Я тесты все руками набираю, как хочу, так и организовываю.

Нет, я про то, что для каждого теста во время выполнения тестов создается новый экземпляр класса теста, в то время как в NUnit-е экземпляр Fixture создается один раз.

Здравствуйте, Tom, Вы писали:

S>>Во-первых, встроенная тулза ОЧЕНЬ долгая. На нескольких тысячах тестов разница заметна на глаз.
S>>Во-вторых, у встроенной тулзы большие проблемы с иерархиями тестов.
Tom>А что такое иерархия тестов?
Ответил выше

S>>В-третьих, у встроенной тулзы возможен разный порядок выполнения тестов, оттого инициализация и деинициализация Fixture производится как-попало. Если в NUnit-е фактически есть гарантия того, что все тесты одного Fixture выполняются подряд между [FixtureSetUp] и [FixtureTearDown], то во встроенной тулзе между этими методами могут быть вызваны другие тесты от других Fixture.
Tom>Разный порядок выполнения — это нормально и даже плюс. Тесты по определению должны быть независимые друг от друга.
Разный порядок — хорошо. Но вот перепутанные инициализации от разных тестов — это зло.

S>>В четвертых, встроенная тулза не производит реюз класса для сценария с несколькими тестами. Для каждого теста класс теста создается заново.
Tom>Это не проблема, это нормально

Допустим, fixture использует некоторые общие данные для нескольких тестов. Генерить их перед каждым тестом — это сказывается на времени выполнения тестов. Складывать их в статические переменные? Это не нормально.

Tom>>А что такое иерархия тестов?
S>Ответил выше
Где выше. Можно ссылку?

Tom>>Разный порядок выполнения — это нормально и даже плюс. Тесты по определению должны быть независимые друг от друга.
S>Разный порядок — хорошо. Но вот перепутанные инициализации от разных тестов — это зло.
Это как вообще?

S>>>В четвертых, встроенная тулза не производит реюз класса для сценария с несколькими тестами. Для каждого теста класс теста создается заново.
Tom>>Это не проблема, это нормально

S>Допустим, fixture использует некоторые общие данные для нескольких тестов. Генерить их перед каждым тестом — это сказывается на времени выполнения тестов. Складывать их в статические переменные? Это не нормально.
Почему это не нормально? Тоесть статические переменные — это не нормально, а один инстанс класса для нескольких тестов — это нормально?

Здравствуйте, Tom, Вы писали:

Tom>>>А что такое иерархия тестов?
S>>Ответил выше
Tom>Где выше. Можно ссылку?
http://www.rsdn.ru/forum/dotnet/3459197.1.aspx

Автор: samius
Дата: 07.07.09

Tom>>>Разный порядок выполнения — это нормально и даже плюс. Тесты по определению должны быть независимые друг от друга.
S>>Разный порядок — хорошо. Но вот перепутанные инициализации от разных тестов — это зло.
Tom>Это как вообще?
По той же ссылке

S>>>>В четвертых, встроенная тулза не производит реюз класса для сценария с несколькими тестами. Для каждого теста класс теста создается заново.
Tom>>>Это не проблема, это нормально

S>>Допустим, fixture использует некоторые общие данные для нескольких тестов. Генерить их перед каждым тестом — это сказывается на времени выполнения тестов. Складывать их в статические переменные? Это не нормально.
Tom>Почему это не нормально? Тоесть статические переменные — это не нормально, а один инстанс класса для нескольких тестов — это нормально?
Один инстанс для нескольких тестов — это классика. Так работает все: NUnit, MbUnit, csUnit. лишь vsts отличилась.
Если бы методы одного теста работали вместе и сразу за ними производилась бы деинициализация fixture, то статические переменные были бы вполне ничего в этом случае. А в той ситуации, что есть — неизвестно когда наступит деинициализация потому статические переменные будут держать ссылки на данные неопределенное время. В программах, активно работающих с памятью это критично.
Допустим — требуется проверить работу алгоритма обработки снимка на реальных данных (большой снимок около 40Мб). Вчитывать его перед каждым тестов в методе SetUp (TestInitialize) не разумно. Хранить его в статической переменной — тоже, т.к. неизвестно, когда наступит FixtureTearDown/ClassCleanup или что-там. (да, это не совсем юнит тест, но можно считать это интеграционным тестом, исполненным в качестве юнит теста)
Внятного сценария работы с такими тестовыми данными для vsts я не вижу.