А что вообще такое юнит тесты?

@Mirmik · Регистрация: 27.02.2014

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

Товарищи...

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

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

@GbaLog- · 31.03.2017, 12:17

Читали?
https://habrahabr.ru/post/169381/

@hoggy · 31.03.2017, 12:20

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

А то у меня складывается мнение, что это какая-то абстрактная концепция

очень даже практичная штука.

давайте на примере.

представьте себе, что я ваш заказчик.

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

как вы будете выполнять такую разработку?
покажите это на конкретном примере.

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

что это за проект?
каким будет исходный код?

опишите последовательность ваших действий
в процессе всей разработки.

@Mirmik · 31.03.2017, 12:26 **[ТС]**

hoggy,
Ок. Я пишу код библиотеки,

C++
1
2
3
long sum(int a, int b) {
    return a + b;
}

делаю к ней заголовочный файл

C++
1
2
3
#ifndef ....
//Суммирует два int.
long sum(int, int);

Делаю Makefile, который собирает so.

Делаю тестовый пример, демонстрирующий работу библиотеки.

C++
1
2
3
4
#include <sum.h>
int main() {
    std::cout << sum(9, 7); << std::endl;
}

Собираю все это в папочку и говорю заказчику, что оно работает.

@volvo · 31.03.2017, 12:32

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

Собираю все это в папочку и говорю заказчику, что оно работает.

А я покупаю эту библиотеку, запускаю вот такой код:

C++
1
2
3
4
#include <sum.h>
int main() {
    std::cout << sum(std::numeric_limits<int>::max() - 5, 7); << std::endl;
}

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

@Mirmik · 31.03.2017, 12:34 **[ТС]**

long long... Я ардуинщик.... У меня int == int16_t.

Неважно. Это не по теме.
Хотя нет... Это ведь как раз по теме...

Не по теме:

P.S. (на самом деле я никогда не использую int и long, из-за таких казусов у меня всегда типы ака int32_t в коде...)

@hoggy · 31.03.2017, 12:36

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

Делаю тестовый пример, демонстрирующий работу библиотеки.

бинго!

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

написали код.

и написали функцию main,
что бы проверить, что это вообще все компилируется,
и работает

вот только маааленькая проблемка.

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

но как вы можете это гарантировать заказчику?

давайте слегда подправим код:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <sum.h>
#include <iostream>
#include <cassert>
int main() {
 
    const int expected = 16; // мы знаем заранее, что 9+7 будет 16
    const int real = sum(9, 7); // и мы ожидаем что сумма будет равна 16
 
    // ставим дебаг проверку,
    // что ожидаемое действительно соответствует реальному
    assert(expected == real); 
 
    std::cout << real << std::endl;
}

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

теперь, наше демонстрационное приложение
можно использовать вместо документации.
оно показывает, как использовать наш механизм

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

собственно, это и есть юнит-тест.

в серьёзной разработке есть куча классов,
функций, логики всякой.

там юнит-тесты актуальны.

например: в одном месте что то поправил, в другом поломалось.
юнит-тесты сразу такое показывают.

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

@Mirmik · 31.03.2017, 12:41 **[ТС]**

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

@Kastaneda · 31.03.2017, 12:52

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

но которую при этом полтора человека понимают, как применять

В более менее больших проектах юнит тестирование используется повсюду. Покрытие кода юнит тестами в какой-то степени (к сожалению на на 100%) гарантирует работоспособность программы.

Помимо этого есть еще немало преимуществ тестов. Например у нас проект, которому уже лет 5, там 100500 файлов и 100500 * 1000 строк кода. Ты, реализовывая новую фичу, где-то что-то поменял, сам быстренько потестил и оно даже работает. Ок, ты хороший программист и сделал свою работу, можешь коммитить/пушить. Но до тебя проектом занимались не на столько хорошие программисты и они сделали так, что меняя алгоритм парсинга IP адреса у тебя ломается вывод в файл, чего ты конечно же не знаешь. Когда ты тестил свою работу, ты проверил только как работает твой новый парсинг и он работает. Как узнать что сломался вывод в файл? Правильно - злобные юзеры тебе об этом напишут после очередного резила. Но это не тру подход. Тру подход - это запустить пачку юнит тестов перед коммитом, которые (если они качественные) сразу выявят эту проблему и ты сможешь ее тут же исправить. Если ты ленивый программист и не хочешь запускать тесты (я ж проверил, оно ж работает), то пушишь изменения на VCS сервер, дальше CI сервер пулит эти изменения и начинает собирать код и прогонять тесты. Если тесты сломались, ты (и твои коллеги) получают письмо на почту, что твой коммит разломал все к херам собачьим, и, несмотря на то, что сегодня пятница и рабочий день как раз закончился, ты сидишь и фиксишь тесты, чтоб CI сервер "горел зелененьким"

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

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

Как понять, что из этого следует проверять тестами?

Правильный ответ - всё.

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

И с сетевым взаимодействием и еще с управлением сложной механикой

Для этого придумали mocking (в гугл "unit testing mocking")

MrGluck · 31.03.2017, 13:19

Я просто оставлю это тут:
https://github.com/philsquared/Catch
По теме можно ещё загуглить TDD.
Остальное, скорее всего, уже сказали.

@hoggy · 31.03.2017, 13:47

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

То есть я делаю отдельный бинарник для юнит тестирования, который прогонит мою библиотеку на корректность?

ага.

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

А если у меня там 300 функций, да еще и с узкими контрактами. И с сетевым взаимодействием и еще с управлением сложной механикой... Как понять, что из этого следует проверять тестами?

существуют специальные фреймворки для тестирования.
которые сильно упрощают, автоматизируют, берут на себя всякую рутину,
в общем, делают процесс написания тестов приятным и комфортным.

подробности работы - это нужно читать доки по конкретному фреймворку.

я предпочитаю google mock.

@Mirmik · 31.03.2017, 13:50 **[ТС]**

ок. Фреймворки покурим. Спасибо.

@Kastaneda · 31.03.2017, 14:00

Не по теме:

У нас тоже на работе gtest/gmock используется. Есть проблема с тестами для многопоточного кода, обходим костылями, но в целом удобный фреймворк

@hoggy · 31.03.2017, 14:09

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

Есть проблема с тестами для многопоточного кода

что за проблема то?

@Kastaneda · 31.03.2017, 14:18

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

что за проблема то?

Ну например в интеграционных тестах реально запускаются несколько потоков и gtest не предоставляет инструментов для управления ими. Где-то на sleep'ах выезжаем (что конечно же в корне не правильно), где-то добавляем свои блокировки на мьютексах, чтоб как-то регулировать очередь исполения.
Т.е. чтоб например проверить код на предмет наличия dead lock'ов приходится еще сверху городить огороды.

@hoggy · 31.03.2017, 14:23

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

Ну например в интеграционных тестах реально запускаются несколько потоков и gtest не предоставляет инструментов для управления ими.

а вы вообще как себе это представляете?

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

Т.е. чтоб например проверить код на предмет наличия dead lock'ов приходится еще сверху городить огороды.

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

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

я не понимаю, какие проблемы с многопоточностью и google тестами?

я в многопоточных тестах просто воссоздаю приближенную к бою среду,
и пинаю запуск)

@Kastaneda · 31.03.2017, 14:27

Не по теме:

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

а вы вообще как себе это представляете?

Так сходу сложно сказать) Может можно было бы придумать, что-нибудь удобное. У них же там много всего удобного, до этого ведь как-то додумались. Задача конечно не тривиальная, но и в гугле далеко не худшие разработчики сидят.

@hoggy · 31.03.2017, 14:32

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

Так сходу сложно сказать) Может можно было бы придумать, что-нибудь удобное. У них же там много всего удобного, до этого ведь как-то додумались. Задача конечно не тривиальная, но и в гугле далеко не худшие разработчики сидят.

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

область применения:
обнаружение дедлоков и прочих фактов зависания треда

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

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@Mirmik techpriest 634 / 213 / 57 Регистрация: 27.02.2014 Сообщений: 1,180

	А что вообще такое юнит тесты? 31.03.2017, 12:13. Показов 6542. Ответов 17 Метки нет (Все метки) Товарищи... А вот все говорят, юнит тесты, юнит тесты... Что дескать, оно тестирует отдельно каждый кусочек программы. А что это вообще такое? Как оно выглядит? Как оно пишется? Куда оно встраивается? А то у меня складывается мнение, что это какая-то абстрактная концепция, с которой все вроде бы соглашаются, но которую при этом полтора человека понимают, как применять... 0

@GbaLog- Любитель чаепитий 3745 / 1801 / 566 Регистрация: 24.08.2014 Сообщений: 6,020 Записей в блоге: 1
	31.03.2017, 12:17
	Читали? https://habrahabr.ru/post/169381/ 1

@Mirmik techpriest 634 / 213 / 57 Регистрация: 27.02.2014 Сообщений: 1,180
	31.03.2017, 12:34 [ТС]
	long long... Я ардуинщик.... У меня int == int16_t. Неважно. Это не по теме. Хотя нет... Это ведь как раз по теме... Не по теме: P.S. (на самом деле я никогда не использую int и long, из-за таких казусов у меня всегда типы ака int32_t в коде...) 0

@Mirmik techpriest 634 / 213 / 57 Регистрация: 27.02.2014 Сообщений: 1,180
	31.03.2017, 12:41 [ТС]
	То есть я делаю отдельный бинарник для юнит тестирования, который прогонит мою библиотеку на корректность? А если у меня там 300 функций, да еще и с узкими контрактами. И с сетевым взаимодействием и еще с управлением сложной механикой... Как понять, что из этого следует проверять тестами? 0

MrGluck Форумчанин 8216 / 5047 / 1437 Регистрация: 29.11.2010 Сообщений: 13,453
	31.03.2017, 13:19
	Я просто оставлю это тут: https://github.com/philsquared/Catch По теме можно ещё загуглить TDD. Остальное, скорее всего, уже сказали. 1

@Mirmik techpriest 634 / 213 / 57 Регистрация: 27.02.2014 Сообщений: 1,180
	31.03.2017, 13:50 [ТС]
	ок. Фреймворки покурим. Спасибо. 0

@Kastaneda
	31.03.2017, 14:00
	Не по теме: У нас тоже на работе gtest/gmock используется. Есть проблема с тестами для многопоточного кода, обходим костылями, но в целом удобный фреймворк 0