Как модульные тесты должны быть зарегистрированы? [закрытый]

You should use a combination of descriptive method names and comments in the doc string. A good way to do it is including a basic procedure and verification steps in the doc string. Then if you run these tests from some kind of testing framework that automates running the tests and collecting results, you can have the framework log the contents of the doc string for each test method along with its stdout+stderr.

Here's a basic example:

class SimpelTestCase(unittest.TestCase):
    def testSomething(self):
        """ Procedure:
            1. Print something
            2. Print something else
            ---------
            Verification:
            3. Verify no errors occurred
        """
        print "something"
        print "something else"

Having the procedure with the test makes it much easier to figure out what the test is doing. And if you include the docstring with the test output it makes figuring out what went wrong when going through the results later much easier. The previous place I worked at did something like this and it worked out very well when failures occurred. We ran the unit tests on every checkin automatically, using CruiseControl.

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

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

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

Этого не произойдет, если имя фикстуры - ClassXTests, имя теста - TestMethodX, а сообщение об ошибке - «Ожидается истина, возвращено ложь». Это признак небрежного написания теста.

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

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

Есть несколько вещей, которые вы можете сделать, чтобы сделать тесты более понятными:

• ясные и описательные названия методов тестирования (уже упомянутые)
• тело теста должно быть ясным и кратким (самодокументируемое)
• абстрагироваться от сложной настройки / демонтажа и т. д. в методах
• подробнее?

Например, если вы есть такой тест:

def test_widget_run_returns_0():
    widget = Widget(param1, param2, "another param")
    widget.set_option(true)
    widget.set_temp_dir("/tmp/widget_tmp")
    widget.destination_ip = "10.10.10.99"

    return_value = widget.run()

    assert return_value == 0
    assert widget.response == "My expected response"
    assert widget.errors == None

Вы можете заменить операторы настройки вызовом метода:

def test_widget_run_returns_0():
    widget = create_basic_widget()
    return_value = widget.run()
    assert return_value == 0
    assert_basic_widget(widget)

def create_basic_widget():
    widget = Widget(param1, param2, "another param")
    widget.set_option(true)
    widget.set_temp_dir("/tmp/widget_tmp")
    widget.destination_ip = "10.10.10.99"
    return widget

def assert_basic_widget():
    assert widget.response == "My expected response"
    assert widget.errors == None

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

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

• создание виджета
• вызов запуска на виджете
• подтверждение того, что код сделал то, что мы ожидали

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

Первая версия метода тестирования следует шаблону Inline Setup . Вторая версия следует шаблонам Creation Method и Delegated Setup .

Обычно я против комментариев, за исключением тех случаев, когда они объясняют «почему» кода. Чтение Чистого кода дяди Боба Мартина убедило меня в этом. Есть глава о комментариях и глава о тестировании. Я рекомендую его.

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