2016-09-19 8 views
1

Предположим, у меня есть сущность, которая создает ветвь SVN во время своей работы. Для выполнения функционального тестирования я создаю несколько практически одни и те же методы (я использую питона UnitTest рамок, но вопрос относится к любой тестовой структуры):Передача параметров на tearDown метод

class Tester(unittest.TestCase): 

def test_valid1_url(self): 
    url="valid1" 
    BranchCreator().create_branch(url) 
    self.assertUrlExists(url) # assume I have this method implemented 

def test_valid2_url(self): 
    url="valid2" 
    BranchCreator().create_branch(url) 
    self.assertUrlExists(url) # assume I have this method implemented 

def test_invalid_url(self): 
    url="invalid" 
    self.assertRaises(ValueError, BranchCreator().create_branch, url) 

После каждого теста я хочу, чтобы удалить полученную ветвь или ничего не делать, если тест не пройден. В идеале я бы хотел что-то вроде:

@teardown_params(url='valid1') 
def test_valid1_url(self): 

def tearDown(self, url): 
    if (url_exists(url)): remove_branch(url) 

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

а) создать поле «used_url» в тестере, установить его в каждом методе и использовать в Teardown:

def test_valid1_url(self): 
    self.used_url="valid1" 
    BranchCreator().create_branch(self.used_url) 
    self.assertUrlExists(url) 
... 
def tearDown(self): 
    if (url_exists(self.used_url)): remove_branch(self.used_url) 

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

б) Использовать отдельный метод, как cleanup(self, url) и вызывать его из любого метода

Есть ли другой подход?

+0

Некоторые из тех, кто считает, что '' tearDown'' никогда не должны быть добавлены в тестовые рамки. Правильное решение '' b''. Я бы создал параметризованный тест с правильной обработкой исключений, чтобы устранить дублирование. – zhon

ответ

0

Я думаю, что решение b) могло бы работать, даже если оно обязано иметь вызов метода помощника в каждом тесте, и это звучит для меня как нечто вроде дублирования. Другим подходом может быть вызов вспомогательного метода внутри функции assertUrlExists. Таким образом дублирование удаляется, и вы можете избежать повторного проверки существования URL-адреса для управления очисткой: у вас есть результат утверждения, и вы можете его использовать.