Есть вот ИТ евангелисты которые толкают про правильные методологии тестирования. Все они уже давно на слуху: разработка через тестирование, тестирование минимальных модулей, с моканием зависимостей, по одному ассерту на тест, и т.д.

Я тут прочитал книжку про тестирование "real world" кода — "The Art Of Unit Testing". И задумался, зачем в разработке применять лучшие методологии, даёт ли это какие-то плюсы. В той книге в качестве примеров "real world" кода выступают два метода, один проверяет, что строка заканчивается на заданную подстроку, а другой складывает числа. На таких примерах всё очень красиво получается, т.к. они взаимодейтсвуют с остальным кодом через две дырки: аргументы и возвращаемое значение.

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

public void LoadSubscriptionUpdates(long userId)
{
    var users = usersService.GetSubscriptions(userId);
    usersServiceRequests.LogServiceCall(userId, users, users.Count);
    
    var lastUpdateTime = updatesRepository.GetLatestUpdateTime();
    var now = timeService.UtcNow;
    
    var updates = usersService.GetUpdates(users.Emails, lastUpdateTime, now);
    usersServiceRequests.LogServiceCall(users.Emails, updates.Count, lastUpdateTime.ToUnixTimeStamp());
    
    var updatesDal = _dataConverter.ToDal(users, updates, lastUpdateTime, now);
    updatesRepository.Add(userId, updatesDal);
}

Если это дело писать через бест практикс:

	TDD c RGR
	перевод: перед тем как писать код, пишем тест который будет фэйлиться.

	OAPT
	перевод: в каждом тесте один ассерт.

	Damp over Dry
	перевод: тесты не шарят общий код.

То в процессе написания рождается такая портянка тестов

[Fact("Should call GetSubscriptions")]
public void ShouldCallGetSubscriptions()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {});
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    usersServiceMock.Verify(s => s.GetSubscriptions(74), Times.Once());
}

[Fact("Should log GetSubscriptions call")]
public void ShouldLogCallGetSubscriptions()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    usersServiceRequestsMock.Verify(s => s.LogServiceCall(74, users, 10), Times.Once());
}

[Fact("Should call GetLatestUpdateTime")]
public void ShouldGetLatestUpdateTime()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    updatesRepositoryMock.Verify(s => s.GetLatestUpdateTime(), Times.Once());
}

[Fact("Should call GetUtcNow")]
public void ShouldGetUtcNow()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    timeServiceMock.Verify(s => s.UtcNow(), Times.Once());
}

[Fact("Should call GetUtcNow")]
public void ShouldGetUpdates()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    usersServiceMock.Verify(s => s.GetUpdates(new[] {"email1", "email2" }, lastUpdateTime, now), Times.Once());
}

[Fact("Should convert to dal")]
public void ShouldConvertToDal()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    dataConverterMock.Verify(s => s.ToDal(users, updates, lastUpdateTime, now), Times.Once());
}

[Fact("Should save to updatesRepository")]
public void ShouldSaveToupdatesRepository()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    updatesRepositoryMock.Verify(s => s.Add(userId, updatesDal), Times.Once());
}

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

А в чём плюсы?

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

UPS>Если это дело писать через бест практикс:
UPS>То в процессе написания рождается такая портянка тестов

Вот и не надо им следовать.
OAPT — чушь, вызванная кривостью конкретных тестовых фреймворков (это каким же местом их надо разрабатывать, чтобы не давать к assertʼу возможность пометить конкретную проверку, хотя бы текстовой строкой). Без него уже будет 2-3-кратное сокращение кода тестов в приведённом примере, и тесты станут сопровождаемыми.
TDD — нормально работает только для задач типа "один раз написать что-то не наукоёмкое и забыть", для остальных случаев будет нарушаться, обычно — серьёзно нарушаться. Единственная гарантированно положительная черта — там, где она нужна — это административное принуждение мелких начальников хоть как-то обеспечивать качество продукта.
Про DAMP ничего плохого не скажу, но само по себе это банальность, обычно не требующая отдельного принципа (пока не начинает возводиться в абсолют и мешать остальному). Но с OAPT превращается в маразм.

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

UPS>Есть вот ИТ евангелисты которые толкают про правильные методологии тестирования. Все они уже давно на слуху: разработка через тестирование, тестирование минимальных модулей, с моканием зависимостей, по одному ассерту на тест, и т.д.
UPS>Если это дело писать через бест практикс: TDD c RGR, OAPT, Damp over Dry
Реальный мир сложней любой методологии. Они лишь пример как можно поступить в идеализированном случае. Причем для разных методологий разные идеализации.
Нужно руководствоваться здравым смыслом.

UPS>То в процессе написания рождается такая портянка тестов
UPS>Минусы очевидны. На 14 строк кода без логики, уже родилось 97 строк тестов, на вид не очень полезных.
Правильный вопрос — если ты полагаешь их бесполезными, то и не надо всё эту портянку писать.

UPS>Перед любым изменением тестируемого метода, надо эти горы кода перелопачивать.
ИМХО, одно из назначений тестов — это помощь при рефакторинге, исправлении, оптимизации и прочих изменениях, поэтому по идее, при изменении кода тесты должны либо оставаться прежними, либо меняться не очень сильно. Иначе отчасти теряется их смысл.

UPS>А в чём плюсы?
Смотри, вот ты привел кусок кода. А как ты проверяешь его работоспособность?

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

Тесты это просто один из способов проверки правильности кода. Если их плюсы перевешивают минусы — пиши. Не перевешивают — не пиши.
Единственный момент, советую сделать отдельную ветку в каком-то проекте и на практике попробовать использовать тесты к тем частям которые сейчас разрабатываются/переписываются. Тут как с системами контроля версий, важен опыт, что хранить код в vcs удобней чем не хранить.

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

UPS>Минусы очевидны.
UPS>А в чём плюсы?

Плюс в том, что когда напишешь тесты, сломать код будет сложнее. И опять же код будет именно что протестирован, а не просто потому, что программисту подумалось, что всё нормально. А минус даже не в объёмах тестов. Когда разрабатывается программа у неё изменяется архитектура. Следовательно тесты придётся переписывать, но останется суть того, что они проверяют, ведь без них она будет потеряна.

Мало того, что сторонники TDD описывающие их в книгах приверженцы Agile, так они ещё и наперёд продумывают возможные изменения. Здесь же в чём прикол, как объясняют в книжках, потом вы тесты для программы не напишите, так пишите их до написания кода. Именно до, а не сразу после написания. То есть программист ещё не начал писать работающий код, а тест уже готов и попробуй в него уложиться.

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

Так что здесь вопрос вот в чём:
1. Нужно ли юнит-тестирование?
2. И если всё же нужно, то когда это делать, до написания кода или после?

А если не нужно, тогда:

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

UPS>Есть вот ИТ евангелисты которые толкают про правильные методологии тестирования. Все они уже давно на слуху: разработка через тестирование, тестирование минимальных модулей, с моканием зависимостей, по одному ассерту на тест, и т.д.
UPS>Я тут прочитал книжку про тестирование "real world" кода — "The Art Of Unit Testing". И задумался, зачем в разработке применять лучшие методологии, даёт ли это какие-то плюсы. В той книге в качестве примеров "real world" кода выступают два метода, один проверяет, что строка заканчивается на заданную подстроку, а другой складывает числа. На таких примерах всё очень красиво получается, т.к. они взаимодейтсвуют с остальным кодом через две дырки: аргументы и возвращаемое значение.
По-моему стоит смотреть на решаемую задачу в первую очередь. И тесты обычно должны соответствовать бизнес-требованиям. Обычно, в бизнес-логике есть конкретные юз-кейсы, которые и надо покрывать. Скажем, в твоём примере операция — LoadSubscriptionUpdates. И собственно это и нужно тестировать — что для данного userId вызвался updatesRepositoryAdd с нужной информацией, которая выдаётся всякими вспомогательными сервисами. Т.е. ассерт таки будет один — "updatesRepositoryMock.Verify(s => s.Add(userId, updatesDal), Times.Once());" но эти самые userId и updatesDal составлены правильно и взяты из соответсвующих моков.
Далее. Является ли LogServiceCall частью бизнес-логики без которого программа не считается работоспособной? Если да, то можно сделать второй кейс для проверки. И этот дополнительный кейс сразу говорит о том, что у тебя что-то с дизайном не то... Почему этот LogServiceCall нужно сувать везде постоянно и как не забыть это постоянно тестировать? — Отличное место для рефакторинга, найденное с помощью TDD.

А ещё я не совсем понял как у тебя тест устроен. Как у тебя в тесте проверяется, что именно значение возвращённое из timeService.UtcNow передаётся как параметр в GetUpdates?

Как я понимаю, все эти правила это следствие главного принципа — идеальное покрытие тестами должно однозначно указывать на ошибку в коде. Т.е. одна ошибка (скажем, перепутал параметры long timestamp и long userId) — должна валить ровно один тест. Но, ясное дело, как и любой идеал — недостижимо.

Здравствуйте, ·, Вы писали:
·>А ещё я не совсем понял как у тебя тест устроен. Как у тебя в тесте проверяется, что именно значение возвращённое из timeService.UtcNow передаётся как параметр в GetUpdates?
В Moq в Verify достаточно передать это время как параметр. И тогда он засчитает срабатывание метода, только если он будет вызван с таким же аргументом.

Здравствуйте, m2l, Вы писали:
m2l>Смотри, вот ты привел кусок кода. А как ты проверяешь его работоспособность?

verify'ями из примера выше я проверяю, что кусок кода работает при поведении, которое я мокаю исходя из своих ДОГАДОК, о том, как будут вести себя внешние зависимости. Будет ли работать вся фича, целиком, хрен её знает.

Вот пример.

class TaskProcessor : ITaskProcessor
{
    public void ProcessTask(Task task) // можно тестить обработку всего таска
    {
        while(!IsProcessed(task.Status)) 
        {
            task.Status = taskProcessor.ProcesTaskStatus(task);
            // чего то ещё делаем
        }
    }
}

class TaskStatusProcessor : ITaskStatusProcessor
{
    public void ProcesTaskStatus(Task task) // можно тестить обработку отдельного статуса
    {
        switch(task.Status)
        {
            // процессим конкретные статусы
        }
    }
}

Тут юнит тестами невозможно проверить, что таск вообще в принципе может запроцеситься. Проверить работоспособность я могу, если напишу интеграционный тест, в котором буду тестировать связку TaskProcessor + TaskStatusProcessor.


В целом такие мысли.

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

Получаются такие плюсы.

Можно менять внутренние модули, из которых состоит фича без возни с тестами.
Заодно тестируется БД.
Заодно тестируется многопоточное поведение.
Заодно тестируются временные аспекты. К примеру, операции по таймауту.
Заодно тестируется конфиг.
Не нужно делать угадайки о том, какие данные будут приходить в модули.

Правда о быстром цикле: что-то поправил, запустил тест, ещё что то поправил, запустил тест, можно забыть.
Юнит тесты можно оставить для особых мест.

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

UPS>Есть вот ИТ евангелисты которые толкают про правильные методологии тестирования. Все они уже давно на слуху: разработка через тестирование, тестирование минимальных модулей, с моканием зависимостей, по одному ассерту на тест, и т.д.

Я ограничиваюсь интеграционными тестами, юнит тесты — только для сложных алгоритмов.
А тэорэтики пусть идут лесом.

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

·>Как я понимаю, все эти правила это следствие главного принципа — идеальное покрытие тестами должно однозначно указывать на ошибку в коде. Т.е. одна ошибка (скажем, перепутал параметры long timestamp и long userId) — должна валить ровно один тест. Но, ясное дело, как и любой идеал — недостижимо.

Конкретно в этом случае лучше сделать либо typedef Timestamp long, а потом Timestamp timestaml (или как там его в С++), либо public struct Timestamp {public long Value;} и затем полагаться на проверку типов компилятором. И и юниттесты писать не придётся.

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

UPS>·>А ещё я не совсем понял как у тебя тест устроен. Как у тебя в тесте проверяется, что именно значение возвращённое из timeService.UtcNow передаётся как параметр в GetUpdates?
UPS>В Moq в Verify достаточно передать это время как параметр. И тогда он засчитает срабатывание метода, только если он будет вызван с таким же аргументом.
Тогда ок. Значения параметров надо проверять.

m2l>>Смотри, вот ты привел кусок кода. А как ты проверяешь его работоспособность?
UPS>verify'ями из примера выше я проверяю, что кусок кода работает при поведении, которое я мокаю исходя из своих ДОГАДОК, о том, как будут вести себя внешние зависимости. Будет ли работать вся фича, целиком, хрен её знает.

UPS>Вот пример.
Тут можно юнит-тестом покрыть логику ProcessTask завершения процесса когда статус таска — "завершен".

UPS>Тут юнит тестами невозможно проверить, что таск вообще в принципе может запроцеситься.
Что логично. Ибо это никак проверить нельзя (по крайней мере я не вижу в приведённом коде такого, что это гарантирует).

UPS> Проверить работоспособность я могу, если напишу интеграционный тест, в котором буду тестировать связку TaskProcessor + TaskStatusProcessor.
А вообще говоря да, если код тривиальный, то можно и не юнит-тестить. Он покроется другими тестами.

UPS>В целом такие мысли.

UPS>Полезнее всего тестить максимально жирными интеграционными тестами все модули относящиеся к одной фиче в связке, заменяя стабами неудобные зависимости, к примеру реальные сервисы. Стабы должны отдавать примеры реальных данных.
Интеграционные тесты не заменяют юнит-тесты, а дополняют. Жирных тестов много не напишешь, или они будут работать часами/днями. А юнит-тестами можно покрывать каждую мелочь.
Например, юнит-тестами могу покрыть кучу вариантов и реакции на них — что делать когда имя файла плохое, файл уже существует, файл не доступен для чтения, файл не такого типа и т.п., а в интеграционном тесте скорее всего будет только успешный сценарий когда файл используется как надо.

CM>Я ограничиваюсь интеграционными тестами, юнит тесты — только для сложных алгоритмов.
CM>А тэорэтики пусть идут лесом.

слова не junior-a, но мужа

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

С>·>Как я понимаю, все эти правила это следствие главного принципа — идеальное покрытие тестами должно однозначно указывать на ошибку в коде. Т.е. одна ошибка (скажем, перепутал параметры long timestamp и long userId) — должна валить ровно один тест. Но, ясное дело, как и любой идеал — недостижимо.
С>Конкретно в этом случае лучше сделать либо typedef Timestamp long, а потом Timestamp timestaml (или как там его в С++), либо public struct Timestamp {public long Value;} и затем полагаться на проверку типов компилятором. И и юниттесты писать не придётся.
Ну конкретно тут они оба long. Правильно это или нет — другой вопрос. А в общем случае у тебя всё равно когда-нибдуь будут timestampFrom, timestampTo, userA, userB и т.п.

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

CM>Я ограничиваюсь интеграционными тестами, юнит тесты — только для сложных алгоритмов.
CM>А тэорэтики пусть идут лесом.

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

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

CM>>Я ограничиваюсь интеграционными тестами, юнит тесты — только для сложных алгоритмов.
CM>>А тэорэтики пусть идут лесом.

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

Для унылого клеевого кода типа "взять шарик фарша, макнуть в сухари и плюхнуть на сковородку", коего большинство даже во вполне интересных проектах, юнит-тесты будут только наворачивать строки кода без реальной пользы. Интеграционные тесты (то есть просто функциональные, но более высокого уровня) отлавливают проблемы не хуже, а писать их всё равно надо. А рисовать юнит-тесты (неважно, с TDD или без) чтобы убедиться в том, что и глазами видно, что вызвано A и его результат применён к B... спасибо, я знаю лучше методы потратить время впустую.

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

Но тут к этому всему всплывают злобные административные моменты, которые всё ломают, а именно:
1. В достаточно большой разнородной команде невозможно надеяться на адекватную самооценку каждого программиста. И есть много таких, которые гарантированно попытаются читерствовать, не доработав свою часть.
Ревью от этого помогает, но не сильно.
2. Получив свои условные нормочасы (или как там считают на галерах) за код, он не захочет сам возвращаться к давно забытому коду => требуется административное насилие. А потом ещё разбираться, сколько из уже состоявшейся оплаты вычитать...

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

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

В>А потом месяцами релиз стабилируешь?

Неа.

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

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

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

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

Это же противоречит сути юнит-тестов -- мокировать окружающую среду. А в чем проблема в интеграционном тесте все эти случаи проверить в ручную подкладывая левый файлы?

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

S>·>Например, юнит-тестами могу покрыть кучу вариантов и реакции на них — что делать когда имя файла плохое, файл уже существует, файл не доступен для чтения, файл не такого типа и т.п., а в интеграционном тесте скорее всего будет только успешный сценарий когда файл используется как надо.
S>Это же противоречит сути юнит-тестов -- мокировать окружающую среду.
???!!! В юнит-тестах вроде обычно мокируют всё кроме собственно тестируемого юнита.

S>А в чем проблема в интеграционном тесте все эти случаи проверить в ручную подкладывая левый файлы?
Можно, но будет заметно медленнее. И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.

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

·>???!!! В юнит-тестах вроде обычно мокируют всё кроме собственно тестируемого юнита.

В данном случае придется мокировать тестируемый юнит Берд конечно, но я не представляю себе юнит-тестов для работы с фс. Это уже не ют.

·>Можно, но будет заметно медленнее. И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.

Почему медленнее? Это вообще отдельные тесты, которые такое поведение тестируют. Ну да, боевое окружение, зато по-настоящему.

·>И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.

Запускать тесты из под какого-нибудь guest'а? Или специально настроить соотв. пользователя и с ним все проверять. Ну это уже из области devops.

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

S>·>???!!! В юнит-тестах вроде обычно мокируют всё кроме собственно тестируемого юнита.
S>В данном случае придется мокировать тестируемый юнит Берд конечно, но я не представляю себе юнит-тестов для работы с фс. Это уже не ют.
У тебя может быть юнит поиска и чтения конфиг-файла в разных локациях, например. А все эти вариации "что могло пойти не так" могут быть вызваны в т.ч. и фс.

S>·>Можно, но будет заметно медленнее. И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.
S>Почему медленнее? Это вообще отдельные тесты, которые такое поведение тестируют. Ну да, боевое окружение, зато по-настоящему.
Ну потому что они "слишком большие". Юнит-тестов как правило на порядок-два больше чем интеграционных, и при этом выполняются они все на порядок-два быстрее.

S>·>И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.
S>Запускать тесты из под какого-нибудь guest'а? Или специально настроить соотв. пользователя и с ним все проверять. Ну это уже из области devops.
Во-во. А юнит-тесты по-хорошему обычно запускаются из IDE, ещё до коммита, а не только где-то как-то в специально настроенном окружении. Т.е. юнит-тестом я смогу протестировать/подебажить как мой модуль заработает в условиях нехватки прав и уверенно отдать тестеру/девопу, который потом воспроизведёт это в боевом окружении.

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

CM>Здравствуйте, Ведмедь, Вы писали:

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

CM>Фуфло. Никакие юнит тесты ничего не гарантируют, поскольку от ошибок понимания ТЗ не спасают, и даже для более примитивных багов тоже ничего не гарантируют, поскольку сами могут содержать ошибки.

При чем тут ошибки понимания ТЗ и юнит тесты? До ошибок понимания ТХ надо еще систему поднять с учетом регресса. А вот регресс проверить юнит тесты помогут на самых ранних этапах.

Чисто интереса ради, сколько тестов в вашей тестовой модели? Сколько из них автоматических?

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

·>Ну потому что они "слишком большие". Юнит-тестов как правило на порядок-два больше чем интеграционных, и при этом выполняются они все на порядок-два быстрее.

Я не очень понял, чем юнит-тестирование с фс отличается от интграционных? По времени так точно тоже саме.

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

И как из IDE можно проверить косяки с правами доступа для опеределнного пользователя? Сидеть под его учеткой все время?