Единичное тестирование - журнал, а затем сбой?

Я использую для проверки моего кода. Теперь, когда я новичок в Go, я стараюсь сделать все как можно быстрее. Я использую тестовый пакет в стандартной библиотеке, которая кажется достаточно хорошей. (Мне также нравится, что это еще не внешняя зависимость. В настоящее время мы находимся в 2 зависимостях по сравнению с любым проектом Java или Ruby.....) В любом случае - похоже, что утверждение в golang выглядит так:

func TestSomething(t *testing.T) {
  something := false
  if something {
    t.Log("Oh noes - something is false")
    t.Fail()      
  }
}

Я нахожу эту подробную информацию и хотел бы сделать это на одной строке:

Assert( something, "Oh noes - something is false" )

или что-то в этом роде. Надеюсь, что я пропустил что-то очевидное здесь. Каков наилучший/идиоматический способ сделать это в go?

ОБНОВЛЕНИЕ: просто для уточнения. Если бы я сделал что-то вроде этого:

func AssertTrue(t *testing.T, value bool, message string) {
  if value {
    t.Log(message)
    t.Fail()
  }
}

а затем напишите мой тест следующим образом

func TestSomething(t *testing.T) {
  something := false
  AssertTrue(t, something, "Oh noes - something is false")
}

то это не будет способ go?

Ответ 1

Существуют внешние пакеты, которые могут быть интегрированы с базой тестирования запасов.

Один из них, который я написал давно, gocheck, был предназначен для сортировки такого рода прецедентов.

С ним тестовый пример выглядит так:

func (s *Suite) TestFoo(c *gocheck.C) {
    // If this succeeds the world is doomed.
    c.Assert("line 1\nline 2", gocheck.Equals, "line 3")
}

Вы выполнили бы это как обычно, с go test, и сбой в этой проверке будет отображаться как:

----------------------------------------------------------------------
FAIL: foo_test.go:34: Suite.TestFoo

all_test.go:34:
    // If this succeeds the world is doomed.
    c.Assert("line 1\nline 2", gocheck.Equals, "line 3")
... obtained string = "" +
...     "line 1\n" +
...     "line 2"
... expected string = "line 3"

Обратите внимание, что комментарий, указанный над кодом, был включен в сообщение об ошибке.

Существует также ряд других обычных функций, таких как набор и специфичные для тестирования и сбрасываемые подпрограммы и т.д. Для получения более подробной информации посетите веб-страницу.

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

Для примеров использования gocheck, пожалуйста, посмотрите на пакеты, такие как mgo, goyaml, goamz, pipe, vclock, juju (массивная база кода), lpad, gozk, goetveld, tomb и т.д. Также gocheck, удается проверить себя. Было довольно забавно загружать это.

Ответ 2

Я препятствую написанию теста так, как вам кажется. Не случайно весь stdlib использует, как вы его называете, "подробный" способ.

Несомненно больше линий, но есть несколько преимуществ для этого подхода.

Если вы читаете Почему у Go нет утверждений? и s/error handling/test failure reporting/g, вы можете получить представление о том, почему несколько пакетов "assert" для Тестирование Go не рекомендуется использовать,

И снова доказательство - это огромная база кода stdlib.

Ответ 3

Идиоматический путь - это то, как вы выше. Кроме того, вам не нужно регистрировать какое-либо сообщение, если вы этого не хотите.

Как определено GO FAQ:

Почему у Go нет утверждений?

Go не предоставляет утверждений. Они, несомненно, удобно, но наши опыт заключается в том, что программисты используют их как костыль, чтобы избежать думая о правильной обработке ошибок и отчетности. Правильная ошибка обработка означает, что серверы продолжают работу после нефатальных ошибок вместо того, чтобы рухнуть. Собственная отчетность об ошибках означает, что ошибки прямо и точно, экономя программиста от интерпретации большой авария следы. Точные ошибки особенно важны, когда программист, видящий ошибки, не знаком с кодом.

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

UPDATE
Исходя из вашего обновления, это не идиоматический Go. То, что вы делаете, это, по сути, разработка рамки расширения тестирования, чтобы отразить то, что вы получаете в рамках XUnit. Хотя нет ничего принципиально неправильного, с технической точки зрения, он вызывает вопросы относительно стоимости + стоимости поддержки этой библиотеки расширений. Кроме того, вы создаете собственный стандарт, который потенциально может взломать перья. Самое главное в Go - это не C, Java или С++ или Python, и все должно быть сделано так, как строится язык.

Ответ 4

Но когда вы пытаетесь написать тест, например, дядя Мартин, с одним утверждением в тесте и длинными именами функций, тогда просто утвердите библиотеку, например http://github.com/stretchr/testify/assert может сделать это намного быстрее и проще