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

Question

Я привык тестировать свой код. Теперь, когда я новичок в 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") 
} 

, то это не было бы в идти способ сделать это?

Answer 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, удается проверить себя. Это было очень забавно для этого.

Answer 2

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

В соответствии с определением ГО FAQ:

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

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

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

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

Answer 3

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

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

Если вы читаете Why does Go not have assertions? и s/error handling/test failure reporting/g вы можете получить представление о том, почему несколько «утверждают,» пакеты для тестирования Go не очень хорошая идея использовать,

Еще раз доказательство огромный базовый код из STDLIB.

Answer 4

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