есть ли способ добавить зависимости между unittests в python с помощью модуля unittest? [Дубликат]

Я согласен с тем, что тесты не могут быть заказаны. В некоторых случаях это помогает (проще, черт возьми!) Иметь их в порядке ... в конце концов, это причина для «единицы» в UnitTest.

Тем не менее, одна из альтернатив - использовать макетные объекты для mockout и исправлять элементы, которые должны выполняться до того, как тестируется этот конкретный код. Вы также можете поместить туда фиктивную функцию, чтобы обезопасить свой код. Для получения дополнительной информации ознакомьтесь с Mock, который теперь является частью стандартной библиотеки. Mock

Вот несколько видеороликов YouTube, если вы еще не использовали Mock раньше.

Видео 1

Видео 2

Видео 3

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

import unittest
import sqlite3

class MyOrderedTest(unittest.TestCase):

    @classmethod
    def setUpClass(cls):
        cls.create_db()
        cls.setup_draft()
        cls.draft_one()
        cls.draft_two()
        cls.draft_three()

    @classmethod
    def create_db(cls):
        cls.conn = sqlite3.connect(":memory:")

    @classmethod
    def setup_draft(cls):
        cls.conn.execute("CREATE TABLE players ('draftid' INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 'first', 'last')")

    @classmethod
    def draft_one(cls):
        player = ("Hakeem", "Olajuwon")
        cls.conn.execute("INSERT INTO players (first, last) VALUES (?, ?)", player)

    @classmethod
    def draft_two(cls):
        player = ("Sam", "Bowie")
        cls.conn.execute("INSERT INTO players (first, last) VALUES (?, ?)", player)

    @classmethod
    def draft_three(cls):
        player = ("Michael", "Jordan")
        cls.conn.execute("INSERT INTO players (first, last) VALUES (?, ?)", player)

    def test_unordered_one(self):
        cur = self.conn.execute("SELECT * from players")
        draft = [(1, u'Hakeem', u'Olajuwon'), (2, u'Sam', u'Bowie'), (3, u'Michael', u'Jordan')]
        query = cur.fetchall()
        print query
        self.assertListEqual(query, draft)

    def test_unordered_two(self):
        cur = self.conn.execute("SELECT first, last FROM players WHERE draftid=3")
        result = cur.fetchone()
        third = " ".join(result)
        print third
        self.assertEqual(third, "Michael Jordan")

См. пример WidgetTestCase в http://docs.python.org/library/unittest.html#organizing-test-code , он говорит, что

Теперь экземпляры класса будут запускать один из методов test * * (), при этом self.widget будет создан и уничтожен отдельно для каждого экземпляра.

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

Простым методом для упорядочения тестов «unittest» является следовать механизму init.d, давая им числовые имена:

def test_00_createEmptyObject(self):
    obj = MyObject()
    self.assertIsEqual(obj.property1, 0)
    self.assertIsEqual(obj.dict1, {})

def test_01_createObject(self):
    obj = MyObject(property1="hello", dict1={"pizza":"pepperoni"})
    self.assertIsEqual(obj.property1, "hello")
    self.assertIsDictEqual(obj.dict1, {"pizza":"pepperoni"})

def test_10_reverseProperty(self):
    obj = MyObject(property1="world")
    obj.reverseProperty1()
    self.assertIsEqual(obj.property1, "dlrow")

Однако в таких случаях вам может потребоваться структурировать ваши тесты иначе, чтобы вы могли опираться на предыдущие случаи строительства. Например, в вышесказанном, может иметь смысл иметь функцию «construct и veirfy», которая строит объект и проверяет его назначение параметров.

def make_myobject(self, property1, dict1):  # Must be specified by caller
    obj = MyObject(property1=property1, dict1=dict1)
    if property1:
        self.assertEqual(obj.property1, property1)
    else:
        self.assertEqual(obj.property1, 0)
    if dict1:
        self.assertDictEqual(obj.dict1, dict1)
    else:
        self.assertEqual(obj.dict1, {})
    return obj

def test_00_createEmptyObject(self):
    obj = self.make_object(None, None)

def test_01_createObject(self):
    obj = self.make_object("hello", {"pizza":"pepperoni"})

def test_10_reverseProperty(self):
    obj = self.make_object("world", None)
    obj.reverseProperty()
    self.assertEqual(obj.property1, "dlrow")

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

Возьмем этот тест интеграции в качестве примера:

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

Разделение кода на эти логические фрагменты имеет несколько преимуществ.

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

def test_registration_login_flow(self):
    _test_registration_flow()
    _test_login_flow()

Я согласен с утверждением, что ответ «не делай этого» - плохая реакция.

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

Мое решение состояло в том, чтобы использовать переменные среды операционной системы на моем сервере Bamboo ...

(1) Тест для функции «очистки данных» начинается с цикла while, который проверяет состояние переменной среды «BLOCK_DATA_PURGE». Если переменная «BLOCK_DATA_PURGE» больше нуля, цикл будет записывать запись журнала о том, что он спал 1 секунду. После того, как «BLOCK_DATA_PURGE» имеет нулевое значение, выполнение переходит к проверке функциональности очистки.

(2) Любой юнит-тест, который нуждается в данных в таблице, просто увеличивает «BLOCK_DATA_PURGE» в начале (в настройке ( )) и уменьшает одну и ту же переменную в режиме teardown ().

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

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

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

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

. Из-за этого, если вы читаете say loadTestsFromTestCase и то, что он вызывает, он в конечном счете сканирует методы с некоторым шаблоном имени в любом порядке, в котором они встречаются в словаре методов классов, поэтому в основном в порядке ключа. Он принимает эту информацию и делает testuite для сопоставления ее с классом TestCase. Предоставляя ему вместо этого список, который вы хотите заказать, это один из способов сделать это. Я не уверен в самом эффективном / чистом способе сделать это, но это действительно работает.