Дмитрий

Ну для python уже есть формат для конфигов: это встроенный тип dictionary.

Вы же пишите код на Python и только на нем. За пределами же конфиг ни где не будет использоваться, тогда зачем еще какие-то форматы, когда можно воспользоваться его родными типами?

1. Скачай книгу Мигеля. Это библия по Flask. Без нее как без рук!
2. У меня применяется flask-sqlalchemy , а базу для тестов создаю с помощью sqllite в памяти
3. Для обращения к клиенту, который может посылать запросы к вашему веб-серверу можно юзать client как-то так:

class ApplicationTestCase(unittest.TestCase):

    def setUp(self):
        self.app = create_app(config_name='testing')
        self.app_ctx = self.app.app_context()
        self.app_ctx.push()
        db.create_all()
        self.client = self.app.test_client()

А зачем? Зачем знать язык до идеального состояния? Перфекционизм мучает?

20% труда выдают 80% результата.

Остальные 20% результата потребуют 80% труда. Оно вам нужно?

Другими словами язык должен быть на таком уровне, чтобы вы могли решать задачи. У математиков есть замечательная фраза "Необходимо и достаточно".

Я к тому, что знайте когда остановиться. Хорошее всегда будет врагом лучшего.

1. Начните читать книгу Роя про "Art of Unit testing" уже есть 2 редакция
2. Прочитайте комментарий на ru_SO

теперь касательно ваших методов. К примеру я увидел такой лог выполнения тестов:

AddData_ShouldReturnError() - Failed
AddData_ShouldReturnException() - Failed

Что должен заключить из этих ошибок?

Пытаюсь читать название теста: "Метод AddData должен вернуть ошибку".
Что произошло мне непонятно. Одни вопросы:
* Какие тестовые данные подаются?
* Какое вообще исходное состояние?
* Что принято считать ошибкой? Может быть запись в логе об ошибке, а может быть некорректное значение возвращаемое методом? А может метод должен возвращать False в случае ошибки?

Вот пример, к чему нужно стремиться:

InvalidAdminToken_UsersRequest_ListIsEmpty

Название теста следует схеме именования:

[When]_[Act]_[Then]

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

Если вдруг упало, то вы сразу поймете, что список не пустой! Потому что тестовый метод содержит только и только assert-ы, таким образом ваш тестируемый код выполняемый в Act-части неверный!

*UPD*

Любой модульный тест должен работать согласно паттерну проектирования AAA - Arrange -> Act - > Assert. Т.е. Подготовка к тестированию - Выполнение проверяемого кода - Проверка результатов.

Технически работа модульного теста организовывается так:

setUp() - это подготовка к тестированию, т.е. Arrange
test() - Здесь Act и Assert

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

Тестовый метод это не подготовка результата, это проверка РАБОТЫ вашего БОЕВОГО кода.
Это важно. Очень часто вижу, когда в тест-методы суют небольшие куски кода подготавливающие тест.данные. Это неправильно!!!

Тестовый метод это:
Первым делом выполнить боевой код. Ради него радимого и пишется тестовый метод.
Вторым делом один assert . Да, тестовый метод должен содержать ТОЛЬКО и только одну проверку!

Другими словами не должно быть такого:

assertTrue(usersList is not None)
assertTrue(usersList.isEmpty)

На системах какого масштаба их стоит начинать применять?

К примеру нужно написать класс\метод и возникает вопрос "Когда остановиться?" другими словами, как понять что написанный код работает корректно? Можно глазками отсматривать каждую ветку кода. Можно поставить брэйкпоинты, чтобы посмотреть получаемые значения и в пределах допустимого они или нет. А можно по-другому:

модульные тесты

b = '\x01\x00\x00\x00'.encode()
struct.unpack('<L', b)[0]

Может быть это вам надо?

или это:
int.from_bytes(b, byteorder='little')

В чужой монастырь со своим уставом не ходят. (с) Не мое.

Я к тому, что программируя на C++ нужно с помощью тех способов и идиом, которые привычны ЛЮБОМУ программисту. Самое интересное, имея в своем репертуаре большое кол-во идиом вы приходите к той мысли, что простор для творчества более чем обширен.

dynamic, abstract : 1. Технически можно 2. Но не по плюсовы

Это не модульный тест!
Это интеграционному тест.

Модульный тест проверяет один аспект одной части.
Интеграционный тест проверят несколько частей.

У Вас есть несколько частей:
1. Часть бэкенда понимающяя HTTP
2. Часть бэкенда залезающая в БД
3. Часть бэкенда формирующая ответ
4. Часть бэкенда отправляющая ответ по HTTP

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

посмотрите два теста:

1.
test_sum_a_and_b() - Failed

2.
test_login() - Failed

В каком из этих двух вы быстрее сообразите где фиксать и что фиксать и почему фиксать?

Поступайте более гибко. Чуть чуть теории, чуть чуть практики. Не надо бросаться абсолютно все и вся зубрить и заучивать. Пишите! Уверяю, что Вы быстро поймете насколько освоили материал, который только что прочитали, если не откладывая сразу же начнете что-нибудь писать и попытаетесь применить. Программирование это искуство, иногда некоторые логичные вещи по началу не работают и глаза на лоб лезут "А почему?" и наоборот казалось бы тупейший и нелогичный кусок кода почему-то работает.

чуть-теории - чуть-практики