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

A>просто скажи имя файла.

В каталогах Common, Mapping, Metadata, Reflection можно найти всё. Перелапачивать сейчас сотни тестов нет ни времени ни желания. Тем более, что ты всё равно найдёшь лишь то, что нужно тебе, ведь я прав?

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

IT>Лет 10 назад по форумам шлялись фаны ФП и во всё горло кричали:
IT>- ФП рулез, ООП авно!
IT>Их спрашивали:
IT>- А в чём рулез?
IT>Они отвечали:
IT>- Вы не понимаете! ФП рулез!

Ты так и не понял.

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

ST>Я бы порекомендовал NUnit (MbUnit, xUnit) (в порядке моих предпочтений). NUnit идет первым, поскольку там наиболее навороченная поддержка параетризованных юнит-тестов, что есть очень гуд.

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

(псевдокод)

// test case
{
    var test = (string range) =>
        try
        {
            Interval.Parse(range);
            return true;
        }
        catch (FormatException)
        {
            return false;
        };
        
    check(test("(-Inf,+Inf)") == true);
    check(test("[0,1.5)") == true);
    check(test("(0,0)") == false);
    check(test("[0,-1.12)") == false);
    check(test("(Inf,-Inf]") == false);
    check_exception(() => test(null), typeof(ArgumentNullException));
}

при том что с локальными функциями можно поставить точку останова на строчку с нужным тестом?

IT>Ну т.е. шаманите.

Я не понимаю, что значит "шаманите"? Это стандартные сценарии использования моков. А по вашему — что такое мок и каким должен быть "правильный" мок-фреймворк?

IT>Кстати, я задал попросил привести хотя бы ещё один пример. С этим проблемы как с юзкейсами в AOP?

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

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

A>Пример чего? Перехвата метода и детура на наш делегат? Или просто сценария, который исключительно трудно протестировать без применения моков?

Второе.

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

A>при том что с локальными функциями можно поставить точку останова на строчку с нужным тестом?

Я тоже не понял особо зачем параметризованные тесты нужны, ведь набор провалившихся тестов с проблемами в разных частях диапазона — это лучше, чем один провалившийся тест на все диапазоны сразу (или может там на атрибутах построена особая магия, которая выдаёт нарушения диапазона значений сразу по всем атрибутам?).
Приведённый выше пример страдает той же проблемой — провалится один тест, а проблем внутри может быть сразу много. Да и отлаживать тесты — это то ещё кощунство.

--
С Уважением, Andir!

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

A>чем они лучше чем обычная локальная функция?

Тем, что при провале тесты сразу видно какое значение провалилось. Тем, что можно отлаживать тест для конкретного значения, не ожидая пока прокрутятся все предыдущие. Тем, что можно сказать написав 10 тестов со ста значениями, что у нас в программе 1000 тестов.

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

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

A>>чем они лучше чем обычная локальная функция?

IT>Тем, что при провале тесты сразу видно какое значение провалилось.
с локальной функцией тоже. все зависит от фреймворка.
IT>Тем, что можно отлаживать тест для конкретного значения, не ожидая пока прокрутятся все предыдущие.
во первых юнит-тесты должны прокручиваться *мгноменно*.
во вторых, можно закомментировать лишние строчки, или поставить точку останова на 1й, и в отладчике пропустить не нужные тесты (в MSVS — стрелочку перетащить)
IT>Тем, что можно сказать написав 10 тестов со ста значениями, что у нас в программе 1000 тестов.
с локальной функцией тоже.

еще раз, два куска кода:

[TestCase]
public void Test_Interval_Validity()
{
    var test = (string range) =>
        try
        {
            Interval.Parse(range);
            return true;
        }
        catch (FormatException)
        {
            return false;
        };
        
    check(test("(-Inf,+Inf)") == true);
    check(test("[0,1.5)") == true);
    check(test("(0,0)") == false);
    check(test("[0,-1.12)") == false);
    check(test("(Inf,-Inf]") == false);
    check_exception(() => test(null), typeof(ArgumentNullException));
}

[TestCase("(-Inf,+Inf)", Result = true)]
[TestCase("[0,1.5)", Result = true)]
[TestCase("(0,0)", Result = false)]
[TestCase("[0,-1.12)", Result = false)]
[TestCase("(Inf,-Inf]", Result = false)]
[TestCase(null, Result = false, ExpectedException = typeof(ArgumentNullException))]
public bool Test_Interval_Validity(string range)
{
    try
    {
        Interval.Parse(range);
        return true;
    }
    catch (FormatException)
    {
        return false;
    }
}

в чем разница?

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

IT>>Тем, что при провале тесты сразу видно какое значение провалилось.
A>с локальной функцией тоже. все зависит от фреймворка.

А у меня не зависит. Я просто вижу в решарпере и всё.

IT>>Тем, что можно отлаживать тест для конкретного значения, не ожидая пока прокрутятся все предыдущие.
A>во первых юнит-тесты должны прокручиваться *мгноменно*.

Ага, мгновенно в отладчике через все точки останова.

A>во вторых, можно закомментировать лишние строчки, или поставить точку останова на 1й, и в отладчике пропустить не нужные тесты (в MSVS — стрелочку перетащить)

Можно ещё и гланды вырезать через одно место автогеном, но это как-то неудобно.

A>в чем разница?

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

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

A>в чем разница?

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

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

IT>В каталогах Common, Mapping, Metadata, Reflection можно найти всё. Перелапачивать сейчас сотни тестов нет ни времени ни желания. Тем более, что ты всё равно найдёшь лишь то, что нужно тебе, ведь я прав?

да. это точно, там можно найти многое.

больше всего мне понравился конструктор MemberAccessor, https://github.com/linq2db/linq2db/blob/master/Source/Reflection/MemberAccessor.cs
эпичный говнокод. даже с комментариями.

тестирование глобального состояния в DefaultValueTest.cs меня тоже очень порадовало, особенно его откат в каждом методе.

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

A>больше всего мне понравился конструктор MemberAccessor, https://github.com/linq2db/linq2db/blob/master/Source/Reflection/MemberAccessor.cs
A>эпичный говнокод. даже с комментариями.

Потому что большой и всё в одном месте? Так это классно, чувак! Если ты всегода размазываешь свою логику по методам в две строчки, то это у тебя уже даже не говнокод, а жидкий поноскод. Так что учись пока я жив.

A>тестирование глобального состояния в DefaultValueTest.cs меня тоже очень порадовало, особенно его откат в каждом методе.

Да я уже и так всё понял. Твоего кода мы конечно же не увидим с крутыми моками не высосанными из пальца?

Кстати, смотря мой код ты так и не предложил куда там можно затолкать моки. Или по-твоему нужно всё передизайнить, чтобы они туда таки тулились?

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

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

A>>больше всего мне понравился конструктор MemberAccessor, https://github.com/linq2db/linq2db/blob/master/Source/Reflection/MemberAccessor.cs
A>>эпичный говнокод. даже с комментариями.

IT>Потому что большой и всё в одном месте? Так это классно, чувак! Если ты всегода размазываешь свою логику по методам в две строчки, то это у тебя уже даже не говнокод, а жидкий поноскод. Так что учись пока я жив.

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

A>>тестирование глобального состояния в DefaultValueTest.cs меня тоже очень порадовало, особенно его откат в каждом методе.

IT>Да я уже и так всё понял. Твоего кода мы конечно же не увидим с крутыми моками не высосанными из пальца?

если бы у меня был опенсорс с подходящей архитектурой — показал бы.

вот я написал недавно прогу которая складывает два числа.
в ней 1 юнит, функция add(), и тот ни от чего не зависит.
очевидно что моки для тестирования такой проги не нужны.

IT>Кстати, смотря мой код ты так и не предложил куда там можно затолкать моки. Или по-твоему нужно всё передизайнить, чтобы они туда таки тулились?

из того что я видел, в твоем коде моки не нужны, т.к. у юнитов нет зависимостей.

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

IT>>Потому что большой и всё в одном месте? Так это классно, чувак! Если ты всегода размазываешь свою логику по методам в две строчки, то это у тебя уже даже не говнокод, а жидкий поноскод. Так что учись пока я жив.

A>дело не в количестве строчек, а в SRP. у метода может быть 100 строчек, но он должен отвечать за одну штуку, а не за "сделать геттер, сделать сеттер, поковырять в носу"

Это всё опять догмы, которые при этом всеми трактуются по разному. Я могу сказать, что этот метод делает одну штуку — инициализацию объекта. Инициализация сложная, но разбиение на методы не даст ровным счётом ничего, ни понимабельности (только ухудшит), ни улучшения поддержки (только запутает).

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

A>также я заметил что когда смотрищь на гитхабе, то код не влазит по ширине.

У меня дома три монитора один посередине 24-х дюймовый, нафига мне экономить? На гитхабе я код смотрю несколько раз в год, а дома каждый день.

A>в ней 1 юнит, функция add(), и тот ни от чего не зависит.
A>очевидно что моки для тестирования такой проги не нужны.

Так же очевидно, что дизайн можно сделать как стремящимся к зависимостям от чего-нибудь, так и не стремящимся. Если всё оправдывать наличием моков, то дизайн всячески и со страшной силой будет стремится к зависимостям. Это тоже очевидно. Я, к примеру, ни разу не видел ни одного приложения, где можно было сделать дизайн без моков. Поэтому и спрашиваю вас рассказать и показать.

IT>>Кстати, смотря мой код ты так и не предложил куда там можно затолкать моки. Или по-твоему нужно всё передизайнить, чтобы они туда таки тулились?
A>из того что я видел, в твоем коде моки не нужны, т.к. у юнитов нет зависимостей.

Вот, о чём и речь.

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

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

A>>Пример чего? Перехвата метода и детура на наш делегат? Или просто сценария, который исключительно трудно протестировать без применения моков?

IT>Второе.

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

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

A>прочитал этот пост в блоге, и не понял зачем эти атрибуты нужны.
A>чем они лучше чем обычная локальная функция?

A>(псевдокод)
A>

A>// test case
A>{
A>    var test = (string range) =>
A>        try
A>        {
A>            Interval.Parse(range);
A>            return true;
A>        }
A>        catch (FormatException)
A>        {
A>            return false;
A>        };
        
A>    check(test("(-Inf,+Inf)") == true);
A>    check(test("[0,1.5)") == true);
A>    check(test("(0,0)") == false);
A>    check(test("[0,-1.12)") == false);
A>    check(test("(Inf,-Inf]") == false);
A>    check_exception(() => test(null), typeof(ArgumentNullException));
A>}
A>

В данном случае смешиваются тест-кейс с тестовыми данными. При этом, как будет вести себя тест, если вторая строка свалится? Упадет или пойдет дальше? Или этот велосипед накопит все поломанные тесты и сгенерирует AggregateException со всеми поломанными тестами? Будем ли мы видеть в тест-эксплорере один тест или 6?

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

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

Мы-то все знаем, как писать использовать тру ООП в голом С, но при этом уровень шума при чтении такого кода будет заоблачным. В этом случае проблема аналогична.

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


A>>при том что с локальными функциями можно поставить точку останова на строчку с нужным тестом?

A>Я тоже не понял особо зачем параметризованные тесты нужны, ведь набор провалившихся тестов с проблемами в разных частях диапазона — это лучше, чем один провалившийся тест на все диапазоны сразу (или может там на атрибутах построена особая магия, которая выдаёт нарушения диапазона значений сразу по всем атрибутам?).

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

A>Приведённый выше пример страдает той же проблемой — провалится один тест, а проблем внутри может быть сразу много. Да и отлаживать тесты — это то ещё кощунство.

Вот именно эта проблема и решается параметризованными тестами!

Следующий тест:

[TestCase("(-Inf,+Inf)", Result = true)]
[TestCase("[0,1.5)", Result = true)]
[TestCase("(0,0)", Result = false)]
[TestCase("[0,-1.12)", Result = false)]
[TestCase("(Inf,-Inf]", Result = false)]
[TestCase(null, Result = false, ExpectedException = typeof(ArgumentNullException))]
public bool Test_Interval_Validity(string range)
{
    try
    {
        Interval.Parse(range);
        return true;
    }
    catch (FormatException)
    {
        return false;
    }
}

Тест-раннером разворачивается в 6 (!) независимых тест-кейсов, каждый из которых запускается независимо:



И если один из тест-кейсов упадет, то мы увидим в точности то, что упало:



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

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

IT>>Зачем — это как раз мой вопрос.
Tom>зачем что? блин сломалась мыслечиталка

IT выше утверждал, что моки не нужны. Т.е. его вопрос, зачем нужны моки, как я понял.

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

ST>В данном случае смешиваются тест-кейс с тестовыми данными.

В смысле? В:

[TestCase("[0,1.5)", Result = true)]

не смешиваются и всё хорошо, а

check(test("[0,1.5)") == true);

смешиваются и ужас?
Вот ведь мощь декларативщины чего творит!

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

A>>прочитал этот пост в блоге, и не понял зачем эти атрибуты нужны.
A>>чем они лучше чем обычная локальная функция?

ST>В данном случае смешиваются тест-кейс с тестовыми данными.
нет. кейс в функции test, данные отдельно, после нее.

ST>При этом, как будет вести себя тест, если вторая строка свалится? Упадет или пойдет дальше?
с check() пойдет дальше, с require() остановится. я всегда использую require().

ST>Или этот велосипед накопит все поломанные тесты и сгенерирует AggregateException со всеми поломанными тестами? Будем ли мы видеть в тест-эксплорере один тест или 6?
можно и без исключений, каждый провалившийся check/require добавляет строчку в отчет.
тест-эксплорер не нужен, достаточно прочитать в отчете "все тесты OK", или список строчек в которых тесты провалились.

ST>Мы-то все знаем, как писать использовать тру ООП в голом С, но при этом уровень шума при чтении такого кода будет заоблачным. В этом случае проблема аналогична.
отнюдь. если говорить о коде, я вижу шум в виде "Result=" в параметризированных тестах, и не вижу шума в своем варианте.