20150512

Писать или не писать код

Расскажу прохладную былину.
Пасусь я, стало быть, как-то на кодакадеми, пилю задачку.
Допилил.
Работает, отлично.
Потом думаю такой: "Так я ж тестер, как бы мне её поломать?"
Всё по постулатам начал делать. Сначала прикинул набор тестов на позитивные значения, потом на негативные, потом на невозможные.
Ну мне просто - это же я писал, знаю как что там работает.
Начал навешивать защиту от дурака и прочее.
В общем, получилось стабильно работающее, неповоротливый и тормозной мамонт с хардкодом, кучей валидаций и исключений  вместо пары десятков строк кода.
И тут я понял, что тестер кодить не должен.
Смотреть код - да.
Понимать - да.
Но сам кодить -  нет.
Только в рамках самообразования.
А ещё стало жалко девелоперов и стало понятно почему проще оставить дырку или костыль.
Не исключено, что подобная  ситуация у меня получилась исключительно из за близости места произрастания рук к седалищному нерву, но всё же хочется значть ваше мнение.

КПЗ: "Ошибка"



15 комментариев:

  1. Анонимный5/12/2015 04:58:00 AM

    Тестить свой код и тестить чужой - это очень разные вещи :)

    ОтветитьУдалить
    Ответы
    1. Спасибо, Кэп! ) Продолжайте наблюдение )
      Да даже не только тестить, но и просто читать. Но что из этого следует?

      Удалить
  2. Ну дело такое.

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

    Деталей не знаю, исхожу из очень общих соображений.

    ОтветитьУдалить
    Ответы
    1. Деталей нет, поэтому утверждать нечего.

      Исходи из соображений высокого порядка, вроде "функционал отдельно, описание отдельно, проверки отдельно", и всё такое. Если получился монстр, значит, принцип KISS не работает.

      Удалить
  3. Анонимный5/12/2015 07:36:00 AM

    Что делать, если для тестирования кода нужно писать код?

    ОтветитьУдалить
    Ответы
    1. Проектировать код, потом писать код. А в чем был вопрос?

      Удалить
    2. Анонимный5/12/2015 08:45:00 AM

      "И тут я понял, что тестер кодить не должен."

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

      Удалить
    3. Я имел ввиду, что если это сервисный код, то есть служащий для автотестирования или в роли стаба, то да. А если код продуктовый, то нет.

      Удалить
  4. Приложение, обрабатывающее все кейсы, сложнее, чем код работающий по основному сценарию? Ну да, факт примечательный, но дальше логическая цепочка у меня обрывается) Если получился неповоротливый и тормозной мамонт с хардкодом - ну, значит плохо написал. Давай код, обсудим, в чем проблема и как можно сделать лучше (если он конечно не на брейнфаке).

    ОтветитьУдалить
    Ответы
    1. Код на рубях. Обсуждать нет смысла, потому что он остался фиг знает где )
      Я не исключаю вариант, что плохо написал, спорить не буду.
      Я к тому, что можно "сервисный код" усложнять до потери пульса, придумывая всё новые и новые кейзы.

      Удалить
    2. Тогда значит руки кривые :) Шучу конечно, но в руби действительно полно фишек, которые делают код значительно более читаемым, тут подходы несколько менее прямолинейные, чем например в джаве.

      Насчет обработки кейсов - код должен предусматривать все ситуации. Другое дело, что существуют юнит-тесты, стратегии управления исключениями (failfast например), контрактное программирование и другие подходы, которые подсказывают, каким образом управлять валидацией и обработкой исключительных ситуаций. Это скилл программирования - понять, где и как надо обрабатывать редкие кейсы. И чем лучше программист, тем лучше он видит все возможные варианты.

      Удалить
    3. >Насчет обработки кейсов - код должен предусматривать все ситуации

      Воу, воу, палехщи.

      Удалить
    4. Все ситуации, предусмотренные спецификацией, разумеется. Дискасс?))

      Удалить

Ваш комментарий очень важен для нас.