Python-сообщество

http://www.youtube.com/watch?v=l1wKO3rID9g

Над моментом с QA ржал :)

PS: Не покажите, где можно посмотреть практическое описание тест-драйвен разработки? Ну с примерами кода, “сацес стори” так сказать. Как можно более близкое к реальности.
А то я как-то никак не въеду в чём профит

Практическое описание…. TDD для чайников? Не знаю, не видел. Читал Бека и всякое-разное по блогам и проч.
У нас техпроцесс на самом деле что-то вроде этого.
На самом деле, как по мне, не важно - тесты вначале или в конце. Главное - чтобы они были.
Да вот только если на последний момент откладываешь - то никогда их не пишешь.

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

Да, и TDD ни в коем случае не отменяет отдел QA.

Если чего-то недорассказал - спрашивай.

Ferroman
PS: Не покажите, где можно посмотреть практическое описание тест-драйвен разработки? Ну с примерами кода, “сацес стори” так сказать. Как можно более близкое к реальности.
А то я как-то никак не въеду в чём профит

Андрей Светлов
Скорее не “для чайников” а сама иллюстрация “выгоды” от подхода. Может есть исходники где это хорошо проиллюстрировано?
Я вот на свой код смотрю - ну вижу пару мест, где можно тесты написать. Но много и таких, что вообще непонятно как их проверять.
j2a
О, интересно.
А тег урл меня уже вусмерь заколупал.

Ferroman
Я вот на свой код смотрю - ну вижу пару мест, где можно тесты написать. Но много и таких, что вообще непонятно как их проверять.

Ferroman
А тег урл меня уже вусмерь заколупал.

ZZZ
Кстати, иногда я использую, назову так, “связанные тесты”. /…/
Мне вот интересно, такой подход вообще нормален? Просто что-то мне подсказывает, что тесты должны быть обособленными и всё-таки как-то это не так…

P.S. У меня нет нормальной сети (GPRS), так что ю-туб для меня закрыт. :-(

Отредактировано (Июнь 25, 2009 05:17:21)

j2a
Это не нормально, тесты должны быть несвязными. Более того, есть тест-фреймворки (afair, twisted trial) которые прогоняют тесты в случайном порядке, чтобы гарантировать несвязность.

def func_01():
    ...тело первого теста...

@setup(...)
def test_01():
    func_01()

def func_02():
    func_01()
    ...тело второго теста...

@setup(...)
def test_02():
    func_02()

j2a
http://www.slideshare.net/j2a/about-uni … g/download

Отредактировано (Июнь 25, 2009 05:45:09)

ZZZ

j2a
Это не нормально, тесты должны быть несвязными. Более того, есть тест-фреймворки (afair, twisted trial) которые прогоняют тесты в случайном порядке, чтобы гарантировать несвязность.

И как тогда в этом случае поступать? Первая мысль – вызывать предыдущий тест как просто функцию из следующего, но тогда setup и teardown для этой функции тоже будут вызываться и, соответственно, всё подчищать.

def _make_files():
    ...

def _clean_files():
    ...

def _make_db():
   ...

def _clean_db():
   ...

class FileRelatedTestCase:
    def setUp(self):
        _make_files()
    
    def testFilesModification(self):
        ...
    def tearDown():
        _clean_files()

class FileAndDbTestCase:
    def setUp():
        _make_files()
        ...
        _make_db()
    
    def testDbExport(self):
        ...
    def tearDown():
        _clean_db()
        ...
        _clean_files()

Нет, я не о том.
Просто объём того, что у меня называется “создать файлы” довольно велик и замечательно идёт именно как первый тест. Один, большой и чёткий.
Ладно, спасибо, попробую разбить это как-нить и посмотреть, что из этого получится. :-)

Добавленно:

j2a
Факт из жизни: код тестов всегда больше кода юнита.

Отредактировано (Июнь 26, 2009 01:32:32)