ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Unit тесты C#
20 сообщений из 20, страница 1 из 1
Unit тесты C#
    #39340540
Eolt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Eolt
Участник
Никогда не писал юниты-тесты, но вот появилась такая задачка:

 
есть функция ReplaceString (string path), принимающая на вход путь до папки и заменяющая во всех файлах (*.*) папки и её вложенных папок все вхождения строк AAA на BBBB. Нужно написать unit-тесты для ReplaceString
.

Т.е. нужно нагенерить структуру папок и файлов со строками AAA и дальше передать ее в ReplaceString, а потом оценить изменения?
Чето дофига сложно выходит!
...
Рейтинг: 0 / 0
03.11.2016, 10:20
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39340574
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
EoltЧето дофига сложно выходит!Да, делать наверное минут 15, не меньше.
...
Рейтинг: 0 / 0
03.11.2016, 10:56
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39340576
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Eolt,

функция разбивается на независимые части:

1. рекурсивный поиск и получения списка путей A
2. обработка списка путей А и получение для каждого элемента из А нового бути Б
2.1. реплейс для одного пути
3. непосредственно переименование

Юнит-тестированию подвергается каждая часть отдельно. Итого:

1. тестируем поиск, для этого нам нужна граничная стуктура папок с файлами, проверяем, что поиск работает верно, очень простой тест

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

3. тестируем реплейс, несколько граничных путей. очень простой тест.

4. тестируем переименование, что любой А переименовывется в любой Б с выбросом нужных исключений при неверных данных. очень простой тест.

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

примерно так работают с юнит-тестами, максимальная декомпозиция и изолированное тестирование.
...
Рейтинг: 0 / 0
03.11.2016, 10:57
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39340607
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Критерии ошибок подобрать по вкусу.
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
public void ReplaceStringTest()
{
    var testDir = CreateTestDirectory();

    try
    {
        if (Directory.GetFiles(testDir , "*AAA*.*", SearchOption.AllDirectories).Length != FilesToRename)
            throw new Exception(......

        ReplaceString(testDir);

        if (Directory.GetFiles(testDir , "*BBB*.*", SearchOption.AllDirectories).Length != FilesToRename)
            throw new Exception(......

        if (Directory.GetFiles(testDir , "*AAA*.*", SearchOption.AllDirectories) != 0)
            throw new Exception(......
    {
    finally
    {
        Directory.Delete(testDir, true);
    }
}
...
Рейтинг: 0 / 0
03.11.2016, 11:07
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39340617
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
* .Length != 0
...
Рейтинг: 0 / 0
03.11.2016, 11:10
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39340636
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Алексей К,

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

надо делать декомпозицию по возможности. функция ReplaceString может использовать internal класс для работы, вот его и надо протестировать, а общий тест функции проверяет, используется ли нужные internal класс или нет, простейший тест.
...
Рейтинг: 0 / 0
03.11.2016, 11:28
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39340646
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
hVosttАлексей К,

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

надо делать декомпозицию по возможности. функция ReplaceString может использовать internal класс для работы, вот его и надо протестировать, а общий тест функции проверяет, используется ли нужные internal класс или нет, простейший тест.Не согласен. Агрегированные показатели (количество) обрабатываемых данных оценивает правильность выполнения с достаточной надёжностью. Ну можно ещё иметь папку, эквивалентную результату выполнения и сравнить с ней. Тогда программа получится чуть проще, тестовых данных потребуется чуть больше.

Тут главное, что я не вижу смысла в данном случае в том, чтобы тестировать внутренности ReplaceString отдельно друг от друга.
...
Рейтинг: 0 / 0
03.11.2016, 11:40
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39340695
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Алексей КНе согласен. Агрегированные показатели (количество) обрабатываемых данных оценивает правильность выполнения с достаточной надёжностью. Ну можно ещё иметь папку, эквивалентную результату выполнения и сравнить с ней. Тогда программа получится чуть проще, тестовых данных потребуется чуть больше.

Для этого существуют интеграционные тесты, они не имеют отношение к юнит-тестированию. Оценивается как раз вход и выход, без учёта внутренностей (black box).

Юнит-тестирование, это white-box тестирование, ты знаешь как устроен тестируемый модуль, имеешь доступ к internal-членам и тестируешь именно правильную работу модуля: вызываются ли нужные методы интерфейсов, в правильном ли порядке они вызываются, генерируются ли нужные исключения, правильно ли обрабатываются ошибки.

Чем сильнее декомпозиция юнит-тестов, тем проще и качественней тесты. Таким образом тестами покрывается буквально каждая строка кода модуля. Любой чих контролируется, это даёт гарантии коду, который использует модуль. Вот это и есть юнит-тестирование.

А так-то можно написать что угодно и обозвать это юнит-тестом. Может где-нибудь и прокатит.
...
Рейтинг: 0 / 0
03.11.2016, 12:16
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39340696
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Алексей КТут главное, что я не вижу смысла в данном случае в том, чтобы тестировать внутренности ReplaceString отдельно друг от друга.

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

А создание кучи папок-файлов, чтобы проверять работу реплейсера (именно замены), это слишком расточительно и не гарантирует работу модуля, не защищает от ошибок. Может на этой структуре, которую ты тестируешь всё работает, а на слегка другой всё сломается. Никаких гарантий.

Хотя сверху можно и таким тестом покрыть, хуже не будет :)
...
Рейтинг: 0 / 0
03.11.2016, 12:20
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39340700
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
hVosttАлексей КНе согласен. Агрегированные показатели (количество) обрабатываемых данных оценивает правильность выполнения с достаточной надёжностью. Ну можно ещё иметь папку, эквивалентную результату выполнения и сравнить с ней. Тогда программа получится чуть проще, тестовых данных потребуется чуть больше.

Для этого существуют интеграционные тесты, они не имеют отношение к юнит-тестированию. Оценивается как раз вход и выход, без учёта внутренностей (black box).

Юнит-тестирование, это white-box тестирование, ты знаешь как устроен тестируемый модуль, имеешь доступ к internal-членам и тестируешь именно правильную работу модуля: вызываются ли нужные методы интерфейсов, в правильном ли порядке они вызываются, генерируются ли нужные исключения, правильно ли обрабатываются ошибки.

Чем сильнее декомпозиция юнит-тестов, тем проще и качественней тесты. Таким образом тестами покрывается буквально каждая строка кода модуля. Любой чих контролируется, это даёт гарантии коду, который использует модуль. Вот это и есть юнит-тестирование.

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

А к общечеловеческим ценностям данные решения не имеют никакого отношения. Для философии нужно вообще выделить отдельный раздел форума, а здесь философию нужно запретить. :-)
...
Рейтинг: 0 / 0
03.11.2016, 12:27
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341133
Doomplay998
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Doomplay998
Участник
EoltНикогда не писал юниты-тесты, но вот появилась такая задачка:

 
есть функция ReplaceString (string path), принимающая на вход путь до папки и заменяющая во всех файлах (*.*) папки и её вложенных папок все вхождения строк AAA на BBBB. Нужно написать unit-тесты для ReplaceString
.

Т.е. нужно нагенерить структуру папок и файлов со строками AAA и дальше передать ее в ReplaceString, а потом оценить изменения?
Чето дофига сложно выходит!
Всё верно Хвост выше написал. И учти, что для хорошо оттестированного кода объём тестов в разы, если не на порядок, превышает объём самого кода. Соответственно, при правке кода нужно в разы больше времени потом уделить правке тестов. Поэтому, когда тебя спрашивают, сколько времени нужно на добавление/изменение такой-то фичи, ты, по программистскому обычаю, бери время в три раза большее, чем тебе кажется, за которое это можно сделать. И потом ещё умножай на 3-5 - для тестов.

 
И документацию на код и на тесты не забудь!
...
Рейтинг: 0 / 0
03.11.2016, 19:26
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341160
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Алексей КТут главное, что я не вижу смысла в данном случае в том, чтобы тестировать внутренности ReplaceString отдельно друг от друга.

Алексей КДа называть это можно как угодно. Я предложил решение, даже два, касающиеся только поставленной задачи. Считаю, что поставленная задача решена.

Код: c#
1.
Assert.That(MyClass.MySuperSum(2, 2), Is.Equals(4));



Ура, задача решена!

Код: c#
1.
2.
3.
4.
5.
6.
7.
public class MyClass
{
   public static MySuperSum(int a, int b)
   {
      return 4;
   }
}



Упс...


Алексей КА к общечеловеческим ценностям данные решения не имеют никакого отношения. Для философии нужно вообще выделить отдельный раздел форума, а здесь философию нужно запретить. :-)

Я описал как вообще подходить к юнит-тестированию в целом, на примере функции ТС. Вообще тесты это дело такое. Целиком и полностью зависит от лени и безответственности разработчиков. Абсолютное большинство вообще тестов никаких не пишут. Чего уж тут пенять на качество тестов. Путь уж будут такие, как ты привёл, чем никакие вообще
...
Рейтинг: 0 / 0
03.11.2016, 20:32
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341169
Doomplay998
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Doomplay998
Участник
hVosttАбсолютное большинство вообще тестов никаких не пишут. Чего уж тут пенять на качество тестов. Путь уж будут такие, как ты привёл, чем никакие вообще
А зачем их писать, если это не какой-то версионный продукт, который надо годами поддерживать, и не разработка в больших командах, где тесты играют роль ТЗ и контроля качества для разработчиков, каждый из которых не понимает и не хочет понимать, как работает система в целом, и где лишь архитектор и несколько приближённых понимают всё от и до?

А модная некогда (щас уже нет) "зряработка через тестирование" - она вообще для одиночек и команд в три человека вредна. Одиночки и тричеловеки всегда делают прототипы, чем бы ни занимались, даже если им кажется, что они переворачивают мир и делают второй Гугл, а значит, забивать своё время всякой бюрократией, к коей несомненно относятся всякие тесты, ТЗ, документация, системы контроля версий и прочий мусор, зря съедающий время, не стоит.
...
Рейтинг: 0 / 0
03.11.2016, 20:44
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341244
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
schi
Участник
Doomplay998А модная некогда (щас уже нет) "зряработка через тестирование" - она вообще для одиночек и команд в три человека вредна. Одиночки и тричеловеки всегда делают прототипы, чем бы ни занимались, даже если им кажется, что они переворачивают мир и делают второй Гугл, а значит, забивать своё время всякой бюрократией, к коей несомненно относятся всякие тесты, ТЗ, документация, системы контроля версий и прочий мусор, зря съедающий время, не стоит.

Да-да. Хренак, хренак и в продакшн.
...
Рейтинг: 0 / 0
03.11.2016, 22:56
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341426
fsharp_fsharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fsharp_fsharp
Участник
Doomplay998hVosttАбсолютное большинство вообще тестов никаких не пишут. Чего уж тут пенять на качество тестов. Путь уж будут такие, как ты привёл, чем никакие вообще
А зачем их писать, если это не какой-то версионный продукт, который надо годами поддерживать, и не разработка в больших командах, где тесты играют роль ТЗ и контроля качества для разработчиков, каждый из которых не понимает и не хочет понимать, как работает система в целом, и где лишь архитектор и несколько приближённых понимают всё от и до?

А модная некогда (щас уже нет) "зряработка через тестирование" - она вообще для одиночек и команд в три человека вредна. Одиночки и тричеловеки всегда делают прототипы, чем бы ни занимались, даже если им кажется, что они переворачивают мир и делают второй Гугл, а значит, забивать своё время всякой бюрократией, к коей несомненно относятся всякие тесты, ТЗ, документация, системы контроля версий и прочий мусор, зря съедающий время, не стоит.

так можно, следуя Вашей логике, прийти к выводу "раз тричеловеки делают прототип (т.е. лажу) - нафиг вообще что-то делать, лучше нанять профессионалов "
...
Рейтинг: 0 / 0
04.11.2016, 13:24
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341463
fsharp_fsharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fsharp_fsharp
Участник
hVostt, а у тебя блога нет? красиво излагаешь, и точно. я бы почитал
...
Рейтинг: 0 / 0
04.11.2016, 15:08
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341464
fsharp_fsharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fsharp_fsharp
Участник
hVosttEolt,

функция разбивается на независимые части:

1. рекурсивный поиск и получения списка путей A
2. обработка списка путей А и получение для каждого элемента из А нового бути Б
2.1. реплейс для одного пути
3. непосредственно переименование

Юнит-тестированию подвергается каждая часть отдельно. Итого:

1. тестируем поиск, для этого нам нужна граничная стуктура папок с файлами, проверяем, что поиск работает верно, очень простой тест

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

3. тестируем реплейс, несколько граничных путей. очень простой тест.

4. тестируем переименование, что любой А переименовывется в любой Б с выбросом нужных исключений при неверных данных. очень простой тест.

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

примерно так работают с юнит-тестами, максимальная декомпозиция и изолированное тестирование.

по-моему, больше ни добавить, ни убавить. в точку
...
Рейтинг: 0 / 0
04.11.2016, 15:10
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341472
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mikron
Участник
schiDoomplay998А модная некогда (щас уже нет) "зряработка через тестирование" - она вообще для одиночек и команд в три человека вредна. Одиночки и тричеловеки всегда делают прототипы, чем бы ни занимались, даже если им кажется, что они переворачивают мир и делают второй Гугл, а значит, забивать своё время всякой бюрократией, к коей несомненно относятся всякие тесты, ТЗ, документация, системы контроля версий и прочий мусор, зря съедающий время, не стоит.

Да-да. Хренак, хренак и в продакшн.
признак профессинала - они так всегда могут.
...
Рейтинг: 0 / 0
04.11.2016, 15:36
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341568
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
winsky!
Участник
че-то ваши юнит тесты совсем не юнит тесты

Unit testing is the practice of testing small pieces of code, typically individual functions, alone and isolated. If your test uses some external resource, like the network or a database, it’s not a unit test.

тут
...
Рейтинг: 0 / 0
04.11.2016, 19:16
| Ответить | Цитировать | Написать  
Unit тесты C#
    #39341748
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Алексей КhVosttпропущено...


Для этого существуют интеграционные тесты, они не имеют отношение к юнит-тестированию. Оценивается как раз вход и выход, без учёта внутренностей (black box).

Юнит-тестирование, это white-box тестирование, ты знаешь как устроен тестируемый модуль, имеешь доступ к internal-членам и тестируешь именно правильную работу модуля: вызываются ли нужные методы интерфейсов, в правильном ли порядке они вызываются, генерируются ли нужные исключения, правильно ли обрабатываются ошибки.

Чем сильнее декомпозиция юнит-тестов, тем проще и качественней тесты. Таким образом тестами покрывается буквально каждая строка кода модуля. Любой чих контролируется, это даёт гарантии коду, который использует модуль. Вот это и есть юнит-тестирование.

А так-то можно написать что угодно и обозвать это юнит-тестом. Может где-нибудь и прокатит.Да называть это можно как угодно. Я предложил решение, даже два, касающиеся только поставленной задачи. Считаю, что поставленная задача решена.
А теперь читаем как звучит задача: Нужно написать unit-тесты .
...
Рейтинг: 0 / 0
05.11.2016, 11:47
| Ответить | Цитировать | Написать  
20 сообщений из 20, страница 1 из 1
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Unit тесты C#
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=20&msg=39340636&tid=1400236]:
 0ms
get settings:
 10ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 52ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 272ms
total:  428ms
созд. / загр.: 428ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]