Тест простого метода

@kotelok · Регистрация: 08.08.2014

Студворк — интернет-сервис помощи студентам

Решил попробовать написть тест для одного из методов, где без тестов реально иногда баги вылезают при доработках.

Метод простой - получает на вход подключение к БД, возвращает в виде многоуровневой структуры объектов информацию обо всей структуре БД (таблицы, колонки, индексы, связи, триггеры и т.п.).

Общая структура теста в итоге получилась такая:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
    [Fact]
    public void ParseDbSchemeTest()
    {
        //
        //Подготовка окружения.
 
        //Подключение к тестовому SQL-серверу.
        using var conn = CreateConnection();
 
        //Создание тестовой БД, создание структуры БД, покрывающей все сценарии.
        var dbName = "sample_db";
        PreapareTestDb(conn, dbName);
 
        //Структура БД для сравнения (загрузка из JSON, например).
        Database expectedDbStructure = PrepareExpected();
 
        //
        //Выполнение тестируемого метода.
        //* через information_schema считывает структуру БД (таблицы, колонки, индексы и т.п.)
        //* и раскладывает её в многоуровевую структуру объктов.
        Database actualDbStructure = new DatabaseParser().Parse(conn, dbName);
        DropTestDb(conn, dbName);
 
        //
        //Проверка результата.
        //* тут полное сравнение структур на всю глубину.
        Assert.True(expectedDbStructure.Equals(actualDbStructure));
    }

Технически, этот тест закрывает все сценарии, когда кто-то вносит некорректные изменения в:
1. SQL-скрипты, которые делают выборку из 'information_schema' в методе 'Parse'.
2. Логику раскладывания данных из 'information_schema' в экземпляр 'Database'.

Однако, если кто-то из разработчиков дополнит обозначенные два пункта новым функционалом, не затронув существующий, тест продолжит корректно продоходить, но при этом фактически не будет покрывать все возможные сценарии метода 'DatabaseParser.Parse'.

Получается, что нужен ещё один тест, который будет контролировать, что структура типа 'Database' (и всех используемых в нём типов, состав всех енумов) строго соответствуют ожидаемому состоянию.

Т.е. получается:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    [Fact]
    public void DbSchemeStructureTest()
    {
        //
        var type = typeof(Database);
 
        //Ожидаемая структура (из JSON, например).
        var expectedTypeInfo = LoadExcpectedTypeStructure(type);
 
        //Разбор (через reflection) структуры типа 'Database' на всю глубину.
        var actualTypeInfo = ParseByReflection(type);
 
        //
        Assert.True(expectedTypeInfo.Equals(actualTypeInfo));
    }

Теперь получается, что если кто-то внесёт изменения в тип 'Database' (или любой используемый в нём тип), то второй тест не пройдёт. Нужно будет внести изменения в метод 'LoadExcpectedTypeStructure'. И где-то там надо будет написать очень заметный комментарий, что в случае внесения изменений в 'LoadExcpectedTypeStructure' нужно согласнованно доработать первый тест, а именно:
1. Дополнить метод 'PreapareTestDb' новыми сценариями.
2. Дописать в 'expectedDbStructure.Equals' логику сравнения для новых свойств/типов.

P.S.: вопрос - как сделать это правильно

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

@HF · 04.06.2025, 13:14

Сообщение от kotelok

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

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

Сообщение от kotelok

Вообще, вроде повсеместно используется. Я на этот вариант в паре статей изначально наткнулся. Потом на гитхабе посмотрел разные популярные проекты, там везде тестовые сборки прописаны в 'InternalsVisibleTo' основных библиотек - Dapper, Avalonia, .NET Runtime и т.п.

Да всё нормально с InternalsVisibleTo. Все этим пользуются, нормальная практика для internal сервисов.

Сообщение от wizard41

Зачем применять рефлекс самому разрабу, который сам же все и пишет? ))

Странный коммент. Это прям тоже самое что и сказать "Зачем тесты писать? вы же код сами пишете, знаете как он работает и какой результат вернёт"

(хмм... прям на belalugoci похоже)

Сообщение от kotelok

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

Есть пара применений рефлексии.
- массовая проверка типов. Например, можно проверить что все Action контроллеров имеют обязательный атрибут. Или что у генерик сервиса существуют все классы, которые определены в его генерик типе. И тому подобные задачи.
- когда действительно не хочется открывать методы на internal или public, но тестировать очень хочется.
Например когда есть приватные свойства которые создаются самостоятельно или для теста их надо менять.
Вот пример библиотеки: Mirrors.
Создаём объект, вызываем метод, меняем приватное свойство, снова тестируем. Или если объект создать поноценно невозможно (всё вокруг moq), то некоторые свойства можно только руками прописать.

@wizard41 · 04.06.2025, 13:27

Сообщение от HF

Странный коммент.

Наверное просто не так был понят. Я имел в виду то, что если эти методы пишет/тестирует сам автор, то зачем их запечатывать в либу и работать с ними ч/з рефлексию?
Сам вопрос, который здесь обсуждается, как-бы рефлексию не предусматривает (не вижу смысла ее применять).

Я считаю, что у kotelok как-то все через-чур переусложнено. Т.е. реально не совсем продумана архитектура: не то самих классов, не то тестов..

@HF · 04.06.2025, 13:39

Сообщение от wizard41

Я считаю, что у kotelok как-то все через-чур переусложнено. Т.е. реально не совсем продумана архитектура: не то самих классов, не то тестов..

Да, тут согласен. Я тему когда увидел, хотел уже написать, но Wolfdp опередил. И уже пошли предложения разбить на части, добавить провайдеров и т.п.

@kotelok · 04.06.2025, 13:43 **[ТС]**

Сообщение от HF

И уже пошли предложения разбить на части, добавить провайдеров и т.п.

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

C#
1
2
3
class Some
{
    ..

C#
1
2
3
static class Other
{
    ..

... и пока что самое просто решение - InternalsVisibleTo.

@HF · 04.06.2025, 13:47

Сообщение от kotelok

Ну т.е. как протестировать классы типа ...

Нет конкретных примеров, но мне кажется что вы перебарщиваете.В примере - приватные классы. Вы хотите приватные классы и методы сервиса тестировать? это точно не нужно. И делать не нужно так и тестировать тоже.

@kotelok · 04.06.2025, 13:59 **[ТС]**

Сообщение от HF

Вы хотите приватные классы и методы сервиса тестировать?

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

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

@HF · 04.06.2025, 14:12

Сообщение от kotelok

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

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

@Wolfdp · 04.06.2025, 14:16

Не по теме:

Сообщение от kotelok

class Some

пишите пожалуйста полностью internal class Some, людям сложно понять что вы имеет в виду...

Не совсем понял в какой момент всплыло private, но думаю не стоит заморачиваться ещё и это покрывать тестами. Приватные методы вызываются публичными, и вам в первую очередь нужно следить чтобы public работал как надо. Если кто-то сломает приватный метод, он потянет за собой паблик, и тесты на это отреагируют (по крайне мере должны).

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

@kotelok · 04.06.2025, 14:20 **[ТС]**

Сообщение от HF

Тогда я всё-таки снова уточню - приватные классы и методы? Потому что в примере именно приватные.

Не, стоп, всмысле приватные?

Вот это вот ...

C#
1
2
3
4
class Some
{
    ..
}

C#
1
2
3
4
static class Other
{
    ..
}

... оно же не приватное, оно именно 'internal' по умолчанию, и эти классы видны тем сборкам, которые в данной сборке указаны через 'InternalsVisibleTo'.

Добавлено через 3 минуты

Сообщение от Wolfdp

пишите пожалуйста полностью internal class Some, людям сложно понять что вы имеет в виду...

А, ок. Я просто вообще ни разу такой записи не встречал. Обычно для классов либо 'public' явно указывается, либо просто ничего не указывается, либо ставится 'private', если надо явно указать, что класс внутренний и снаружи не виден.

P.S.: но вообще да, согласен, без явного указания модификатора не сразу понятно - 'internal' он (если верхнего уровня) или 'private' (если является вложенным в другой класс).

@HF · 04.06.2025, 14:34

Перечитал несколько раз и вроде бы начал смысл парсера понимать. Но возникли другие вопросы - о бессмысленности этого теста.

Сообщение от wizard41

Поздно уже было вчера, видимо я не допер толком до сути вопроса...
Это что-то типа "синхронизации" структуры двух БД? Т.е. где-то там, в БД1 чето поменяли, добавили/удалили таблицы ... на основании этих изменений сформировался json. По этому джсону нужно в точности перестроить некоторую БД2 (на локальной машине)?

Сообщение от kotelok

Ага. Один из сценариев. Но на некоторых проектах БД изначально именно через JSON вручную описывается.

Зацепился за эти комментарии.
Тогда вопрос - ЗАЧЕМ сравнивать? Если это банально мигратор изменений схемы БД, то она должна работать в Одну только сторону (собственно как и все миграторы). Никто ничего не сравнивает. Тупо накладывают изменения. Ну где-то ещё от версии зависит, чтобы знать порядок и количество "патчей".

Ну сравнили вы - узнали что там есть нестыковки. Дальше что делаете? Стоп или начало миграции по новой схеме?
Если стоп - то это ситуация когда каким-то образом кто-то базу обновил. Ну, руки оторвать и дальше нормально работать.
А если миграция, то зачем проверять? обновляй схему и всё. Проверить на различия? для чего?

Добавлено через 3 минуты

Сообщение от kotelok

И есть библиотека, с ровно одним публичным методом, который:
1. На вход принимает JSON с описанием структуры БД и подключение к SQL-серверу (ну и кой-какие параметры).
2. Внутри - загружает JSON (в экземпляр класса 'Dababase), парсит актуальную структуру БД через 'information_schema' (в другой экземпляр 'Database'), строит список различий структуры, строит SQL-скрипты устранения различий, выполняет, логирует, дополнительно верифицирует повторным построением дифа, возвращает ОК (ну или выдаёт исключение, если что-то не так).

Дальше. Вот это я тоже критикую у себя в группе.
Ну и зачем вам база? Ваш метод так и называется - Парсер! Вы его и должны тестировать как парсер.
В тесте должен быть готовый объект с наполнением и на входе в парсер - текст JSON который ваш парсер должен распарсить так чтобы при сравнении (глубоком или банально на количество записей) было всё нормально. Вот - это юнит-тест.

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

@kotelok · 04.06.2025, 14:44 **[ТС]**

Сообщение от HF

Если это банально мигратор изменений схемы БД, то она должна работать в Одну только сторону (собственно как и все миграторы). Никто ничего не сравнивает. Тупо накладывают изменения. Ну где-то ещё от версии зависит, чтобы знать порядок и количество "патчей".

Не-не, от этой духоты и уходил при помощи данного решения. Никаких патчей, никаких версий БД, никаких последовательных миграций с соблюдением порядка:
1. Есть JSON, где описано эталонное состояние БД. Ну т.е. какой она должна быть в данной версии сервиса/программы.
2. Есть конкретный экземпляр рабочей/тестовой/девелоперской БД в каком-то не особо предсказуемом состоянии.
3. Задача модуля - выявить расхождения в структуре и построить скрипт приведения п.2 в состояние, описанное в п.1. И выполнить этот скрипт, если не обнаружилось чего-то совсем уж странного.

@HF · 04.06.2025, 14:52

Сообщение от kotelok

построить скрипт приведения п.2

И как это делается? Билдер построения запроса на, например, добавление/удаления колонки. Не это ли духота? Сначала найди то не зная что, потом ещё и прояви все интеллектуальные силы на восстановление структуры. Круто конечно, но вы где работаете, в хаосе?

Ну и из выше сказанного уже вырисовываются модули
- парсер
который только должен уметь брать текст/JSON и превращать в объект
- сравниватель и определитель цели и возможности для обновления
Или у вас всегда можно обновиться? даже если нет таблицы, то он её создаст, а если были Дабл типы, то преобразует в Инты?
- "ИИ модуль" который при найденных различиях возвращает какой-то результат
например сгененрированный запрос на изменения структуры таблицы

Это на вскидку, пока вижу на что уже можно разбить. Нет смысла тестировать коннекторы и исполнители запросов.
И вот это всё по отдельности и тестируйте.

@kotelok · 04.06.2025, 14:55 **[ТС]**

Сообщение от HF

И как это делается? Билдер построения запроса на, например, добавление/удаления колонки. Не это ли духота?

Не, это облегчает процесс разработки/деплоя. А ещё даёт доп-уверенность, что база реально в ожидаемом состоянии, в отличие от варианта с версионированием БД и последовательным применением патчей.

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

@HF · 04.06.2025, 15:19

Не по теме:

Сообщение от kotelok

Не, это облегчает процесс разработки/деплоя. А ещё даёт доп-уверенность, что база реально в ожидаемом состоянии, в отличие от варианта с версионированием БД и последовательным применением патчей.
Реализация такого модуля да, весьма увлекательное мероприятие. Но зато потом оно очень приятно в использовании.

Конечно же я понял что это УЖЕ сделано и работает и облегчает что-то. Только порадоваться за вас.
Но я ожидал более конкретный ответ на предложение о модулях, которые на мой взгляд и должны быть в сервисе и тесте.

Добавлено через 3 минуты

Сообщение от kotelok

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

Как не понять. Не впервой мне увлекательно придумывать костыли на (свой) легаси код. Только уже давно понял что это плохой путь. Временный для срочных исправлений - хорошо, но постоянный - плохой, чреватый последствиями (сложности в реализации, понимании, будущей поддержке, изменениям).

@kotelok · 04.06.2025, 16:02 **[ТС]**

Сообщение от HF

Ну и из выше сказанного уже вырисовываются модули
- парсер
который только должен уметь брать текст/JSON и превращать в объект
- сравниватель и определитель цели и возможности для обновления
Или у вас всегда можно обновиться? даже если нет таблицы, то он её создаст, а если были Дабл типы, то преобразует в Инты?
- "ИИ модуль" который при найденных различиях возвращает какой-то результат
например сгененрированный запрос на изменения структуры таблицы

Парсер есть. Их даже два. В виде отдельный классов (наборов классов):

1. Первый - берёт JSON и конвертирует его в объект (ну и отдельные модули для валидации, т.к. это пользовательские данные, и дозаполнения значениями по умолчанию согласно параметрам и логике задачи).

2. Второй - берёт подключение к БД и конвертирует информацию о её структуре в объект, аналогичный п.1.
* вот для этого второго пункта в самом первом сообщении была попытка сделать тест.

Сравниватель, да. Тоже отдельный модуль. Сравнивает два объекта (результаты п.1 и п.2), определяет расхождения. Он никак не зависит ни от БД, ни от JSON.

Другой модуль, на базе найденных расхождений, строит план обновления БД (ну т.е. выстраивает их в том порядке, в котором их в принципе допустимо выполнить, добавляет доп-шаги, если необходимо).

Следующий модуль - по плану обновления строит конкретные SQL-скрипты.

Далее оно сливается в лог и, если в параметрах вызова указано, применяется к целевой БД.

@HF · 04.06.2025, 17:00

Сообщение от kotelok

P.S.: вопрос - как сделать это правильно ? Потому как сейчас это выглядит слишком громоздко (в плане написания всех вспомогательных методов и подготовки тестовых данных). И не слишком надёжно, т.к. по сути оставляет шанс, что первый тест попросту забудут доработать под новые сценарии, т.к. он просто пройдёт, и его просто не заметят.

и раз всё есть

Сообщение от kotelok

Парсер есть. Их даже два. В виде отдельный классов (наборов классов):
1. Первый - берёт JSON и конвертирует его в объект ...

2. Второй - берёт подключение к БД и конвертирует информацию о её структуре в объект...

Сравниватель, да. Тоже отдельный модуль. Сравнивает два объекта (результаты п.1 и п.2), определяет расхождения. Он никак не зависит ни от БД, ни от JSON.

Другой модуль, на базе найденных расхождений, строит план обновления БД (ну т.е. выстраивает их в том порядке, в котором их в принципе допустимо выполнить, добавляет доп-шаги, если необходимо).

Следующий модуль - по плану обновления строит конкретные SQL-скрипты.

Далее оно сливается в лог и, если в параметрах вызова указано, применяется к целевой БД.

то применяем атрибут и тестим все модули независимо. Такой ответ подойдёт к вопросу по началу темы?

@kotelok · 09.06.2025, 16:01 **[ТС]**

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

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

В итоге на тест всего одного метода много времени потратил, но, учитывая сложность входных/выходных данных, есть ощущение, что не закрыта куча возможных сценариев и, по сути, тест получился не особо полезным. А ещё есть шанс, что во входных/выходных данных могут быть ошибки чисто в силу невнимательности.

P.S.: в общем, как-то слишком уж утомительно получается, и пока не понятно, насколько вообще эффективно с точки зрения какой-то реальной пользы.

@Andrey-MSK · 09.06.2025, 16:11

Сообщение от kotelok

как-то слишком уж утомительно получается

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

Сообщение от kotelok

насколько вообще эффективно с точки зрения какой-то реальной пользы

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

@wizard41 · 09.06.2025, 16:26

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

Тесты поэтому и называются модульными, т.е. должны проверять отдельные модули. Это уже при личном желании можно их все завернуть в один единый тест; однако нужно учитывать, что не каждый сразу разберется что тут происходит и кто кому передает флаг успеха/провала.

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

@SmallEvil · 09.06.2025, 20:39

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

А тестирование "черных ящиков", ещё тот прикол.
Это внутренние тесты самого разработчика, и они ведутся самим автором.
И задолго до релиза и сборки.

Или я попал во вселенную где архитектура софта и железа - другая?

p.s. И как уже много раз, явно или косвенно, разжевали, что тесты - это на долгосрочную разработку.
А не: ~~"упал, встал, отжался"~~"продал и забыл".

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

p.p.s Какой то планировщик с отчетами для радио прошлого века, наформошлепил... очень авторитетное мнение.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@kotelok 1341 / 920 / 265 Регистрация: 08.08.2014 Сообщений: 2,775
	09.06.2025, 16:01 [ТС]
	Всё равно как-то чересчур сложно получается. Даже в рамках одного метода. Слишком больше затраты времени на подготовку входных данных для тестов, на подготовку проверочных данных, на кропотливую ручную сверку этих массивов данных, на оформление их либо в виде JSON, либо в виде многостраничных инициализаторов иерархических коллекций прямо в коде. Сравнение двух сложных объектов пока реализовал просто через сериализацию обоих в JSON-строку и проверку их точного совпадения. Но не уверен, что это правильный подход, т.к. возможно влияние сериализатора на результат. В итоге на тест всего одного метода много времени потратил, но, учитывая сложность входных/выходных данных, есть ощущение, что не закрыта куча возможных сценариев и, по сути, тест получился не особо полезным. А ещё есть шанс, что во входных/выходных данных могут быть ошибки чисто в силу невнимательности. P.S.: в общем, как-то слишком уж утомительно получается, и пока не понятно, насколько вообще эффективно с точки зрения какой-то реальной пользы. 0

@wizard41 3453 / 2774 / 575 Регистрация: 04.09.2018 Сообщений: 8,725 Записей в блоге: 3
	09.06.2025, 16:26
	kotelok, если в вашем супер-методе вызываются несколько под-методов, то они все должны быть тестируемые отдельно. Если так не получается или слишком сложно выходит, следовательно имеет место не-доработка общей архитектуры классов. Вероятно, какое-то кол-во методов будет находится прямо в этом же классе, супер-метод которого тестируете. В этом случае создать объект этого класса и подгрузить нужные проверочные данные для каждого из методов - не составит проблем. Если же часть методов находятся в составе другого класса, то это уже объекты других тестов, отдельных. Тесты поэтому и называются модульными, т.е. должны проверять отдельные модули. Это уже при личном желании можно их все завернуть в один единый тест; однако нужно учитывать, что не каждый сразу разберется что тут происходит и кто кому передает флаг успеха/провала. Добавлено через 2 минуты При коллективной разработке "супер-тесты" не приветствуются вообще. А для личных целей можно сделать все что угодно, хотя, при этом нужно действительно представлять себе весь процесс. Иначе получится тестирую то - сам не знаю что. 1

@SmallEvil 4086 / 2975 / 813 Регистрация: 29.06.2020 Сообщений: 11,000
	09.06.2025, 20:39
	kotelok, разбить тесты не означает полностью сменить систему тестирования. Был в этих двух смежных темах коммент с видосами, я просмотрел только вводный. Так вот, тестов на одну и ту же сущность может быть много. А не один спагетти-кот. А тестирование "черных ящиков", ещё тот прикол. Это внутренние тесты самого разработчика, и они ведутся самим автором. И задолго до релиза и сборки. Или я попал во вселенную где архитектура софта и железа - другая? p.s. И как уже много раз, явно или косвенно, разжевали, что тесты - это на долгосрочную разработку. А не: ~~"упал, встал, отжался"~~"продал и забыл". Лично я не представляю толковую программу, которую не тестируют, вот в одиночку даже пишешь и каждую функцию/класс тестируешь, что бы потом не уходить в дебаг часами и днями. p.p.s Какой то планировщик с отчетами для радио прошлого века, наформошлепил... очень авторитетное мнение. 1