Дмитрий

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)

Вы не можете начать тестировать только потому, что Вы решили сначала написать код, а только потом его тестировать. Это неверно! Когда принимается решение писать код, нужно хотя бы где-то описать его задачу. TDD почти один в один взяли подход от математиков. У математиков тоже есть "Дано" - это аналог SetUp и "Нужно сделать" - это аналог вашего тестируемого кода, т.е. то что Вы реализуете и "Чтобы удовлетворяло условиям...." - Это очень похоже на Assert.

Откиньте Ваш код, как будто Вы его еще не написали. Прочитайте формулировки нескольких мат.задач. Посмотрите их стилистику. Как они оформляют мысли при изложении сути задачи. И попробуйте следовать точно также! То есть опишите вашу программерскую задачу до начала решения, как это делают математики.

/Offtop:
Рекомендую Вам выписать возможные случаи при добавлении элемента в список. К примеру:

Позитивные случаи:
* Добавить нормальный элемент;
и т.д. и т.п.

Негативные:
* Добавить Null;
* Добавить когда список уже переполнен - а такое возможно?;
* Добавить когда список, когда не доконца создан - а такое возможно?
и т.д. и т.п.