amarao (amarao_san) wrote,
amarao
amarao_san

тесты

Написание нового кода с тестами очень сильно отличается от "написания тестов к существующему коду". Большинство багов исправляются прямо в процессе написания - и это очень мягкий быстрый процесс. Нужно сколько-то конкретно походить по граблям в терновом кусте, чтобы понять, насколько получается быстрый и мягкий процесс. Точнее, понять, как выглядит процесс, когда он не "мягкий и быстрый".

Вот пример удавленного в зародыше бага:

class BadConfig(TypeError):
    pass

class DuplicateEntry(BadConfig):
    pass


class Config:

    ....
    @staticmethod
    def validate(conf):
        serials = set()
        uuids = set ()
        mountpoints = set()
        slots = set()
        try:
            for entry in conf:
                if entry['slot'] in slots or entry['uuid'] in uuids or entry['serial'] in serials or entry['mountpoint'] in mountpoints:
                    raise DuplicateEntry("%s is duplicate" % str(entry))
                else:
                    slots.add(entry['slot'])
                    uuids.add(entry['uuid'])
                    serials.add(entry['serial'])
                    mountpoints.add(entry['mountpoint'])
            return True
        except (TypeError, KeyError):
            return False


Фейлящийся тест:
def test_validate_duplicate():
    '''Check if validate() rejects duplicate entries'''
    sample = (REAL_DATA[0], REAL_DATA[0])
    assert_raises(DuplicateEntry, Config.validate, sample)


Я не знаю, сколько бы ночей заняла отладка этого бага в реальной ситуации (с реальными жёсткими дисками).

А ведь баг не в коде - в архитектуре. Когда я писал class BadConfig(TypeError), мне это казалось хорошей идеей. А потом мне показалось хорошей идеей ловить TypeError, если на вход всякая ерунда пришла.

И тут оказалось, что DuplicateConfig - подкласс TypeError, и я его сам у себя ловлю. Не было бы тестов - шут знает, в каком месте как оно укусило бы.

Всего фикса - решить, что BadConfig - это просто Exception, а не TypeError. И всего багфикса (процесса тупления над причиной) - минут пять в тепличных условиях простенького кода (когда можно попринтить в удовольствие), а не "адский шредингбаг, появляющийся только (вписать адскую кровавую ситуацию продакшена, когда это актуально).

С другой стороны, чтобы выделить рерсурсы на такое написание, эти ресурсы надо ощущать, как доступные. Потому что я с утра 170 строк тестов написал, а ещё 90 строк основного класса (который для крупного архитектурного фикса предлагается использовать). То есть на выходе - я ещё баг даже не тронул, а уже пол-дня прошло.

И тут чистая война тактики против стратегии. Тактически проще пойти и поправить. Стратегически выгоднее поправить так, чтобы работало.
Tags: программирование
Subscribe

  • one piece

    Ванпис плавно погружается в мир детских психологических травм Санджи, делая его всё более и более похожим на реального человека. Раскрытие…

  • Ванписное

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

  • Ванписнутое

    Внезапно, когда казалось, что ванпис уже совсем не, они, кажется, возвращаются. Как всегда, интересно несовершенство, стремящееся к лучшему, так что…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 3 comments