1. Java / Говнокод #12302

    +62

    1. 1
    2. 2
    3. 3
    4. 4
    @Test(expectedExceptions = UnsupportedOperationException.class)
public void testGetRooms() {
    dao.getRooms(null);
}

    100% покрытие тестами

    Запостил: madhead, 17 Декабря 2012

    Комментарии (10) RSS

    • ava 3.14159265 17.12.2012 19:32 # +1

      Так в чем говно?
      Походу проверка контракта - кидать UnsupportedOperationException при передаче nullа.
      Ответить

      • ava bormand 17.12.2012 19:45 # +3

        Если кто-то считает, что делать тесты с null'ами говно - я первый брошу в него камень.

        Сегодня вот как раз, быдлокодя прогу под ведро, налетел на баг с null'ом. Йода-сравнения строк и StringBuilder сующий в себя "null", если получит null, сделали свое грязное дело - пропустили null и не упали. В результате прога бесконечно читала readLine'ом строки из сокета (получая null), он успешно пролетал мимо всех проверок (на null я проверить как раз и забыл), и уходил на хранение в стрингбилдер. Когда в нем набирался гиг "nullnullnullnull.." прога падала с OutOfMemoryException...

        Если бы я не был лентяем, и написал тест с null'ом для метода, принимающего строку - я бы увидел этот баг сразу. Так что не говно, 3.14159265 плюс, треду минус.
        Ответить

        • ava 3.14159265 17.12.2012 19:52 # +2

          Во всех коллекциях жабы есть строго определенное поведение при передачи nullа.
          Суть интерфейса - это контракт, и это поведение описано в документации.
          Если реализуешь интерфейс - следуй соглашению и пиши юнит-тесты, которые это проверят.
          Вот навскидку:
          Collection.class
          /*
     * If a collection refuses to add a particular element for any reason
     * other than that it already contains the element, it <i>must</i> throw
     * an exception (rather than returning <tt>false</tt>).  This preserves
     * the invariant that a collection always contains the specified element
     * after this call returns.
     *
     * @param e element whose presence in this collection is to be ensured
     * @return <tt>true</tt> if this collection changed as a result of the
     *         call
     * @throws UnsupportedOperationException if the <tt>add</tt> operation
     *         is not supported by this collection
     * @throws ClassCastException if the class of the specified element
     *         prevents it from being added to this collection
     * @throws NullPointerException if the specified element is null and this
     *         collection does not permit null elements
     * @throws IllegalArgumentException if some property of the element
     *         prevents it from being added to this collection
     * @throws IllegalStateException if the element cannot be added at this
     *         time due to insertion restrictions
     */
    boolean add(E e);

          На каждое из 5-ти исключений нужен тест.
          Ответить

          • ava bormand 17.12.2012 20:22 # +1

            > Следуй соглашению и пиши тесты блеать!
            Надо, обязательно надо... но всегда так трудно заставить себя писать тесты, когда есть вдохновление на написание кода...
            Ответить

            • ava 3.14159265 17.12.2012 20:26 # +3

              Вот-вот. Потому я занимаюсь этим малоинтеллектуальным делом когда нет никакой тяги делать что-то серъезное.
              Ответить

    • ava madhead 17.12.2012 21:53 # −1

      Прошу прощения, забыл, что вы не видели всей картины

      getRooms(RoomTypeRequest r){
      throw new UnsupportedOperationException("Operation is not implemented");
      }

      Хотя да: UnsupportedOperationException он для того и существует, чтобы указывать на такое, передали налл - кидай что-нить другое. Но даже если так: зачем проверять нереализованность метода? Вы полагаетесь на этот эксепшен в другом месте? Тогда скидывайте рядом тот код.
      Ответить

      • ava krypt 17.12.2012 22:31 # 0

        TDD?
        http://ru.wikipedia.org/wiki/Разработка_через_тестирование
        Ответить

        • ava madhead 17.12.2012 22:35 # 0

          Нет, не тдд. Просто метод и тест на него. Мы не используем эту методику в разработке.
          Ответить

          • ava krypt 17.12.2012 23:47 # +2

            Но всё равно, пока это похоже на косяк кода, а не теста.
            Ответить

      • ava bormand 18.12.2012 06:05 # 0

        > Но даже если так: зачем проверять нереализованность метода?
        [кэп]Затем, чтобы если его вдруг кто-то додумается реализовать, можно было это заметить и дописать еще тестов?[/кэп]
        Ответить

    Добавить комментарий