LINUX.ORG.RU

Неужели с тестированием так все плохо ?

 


1

2

Сабж ? Речь идет не о просто «hello world», а о Mock обьектах ?

Посмотрел в интернетах - Goлисты пишут, что Mock обьекты из Python как и сам Python - зло, предлагают либо переписать все на интерфейсы, либо забить на тесты.

Но если переписывать на интерфейсы - получается везде нужно пихать switch с преобразованиями, что жутко загромождает код.

Как например я могу протестировать вот такой обьект, замочив ssh.Client ?


type Conn struct {
        SSHClient  *ssh.Client
}
func (conn *Conn) RunCommands(cmds ...string) (string, error) {
conn.SSHClient.Run()
}



Последнее исправление: Jopich1 (всего исправлений: 1)

предлагают либо переписать все на интерфейсы

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

судя по этому

получается везде нужно пихать switch с преобразованиями

ты не понял как пользоваться интерфейсами.

ergo ★★★
()
Последнее исправление: ergo (всего исправлений: 3)

Вообще, один практикующий пони говорил, что тестировать надо
a. интерфейс как чёрный ящик, без этих самых ваших моков
б. реализацию как код, с покрытием строк и влезанием внутрь максимально шаловливыми ручками
Это два довольно-таки разных подхода как по подходу так и по требованиям к инструментарию, и не надо их смешивать.

izzholtik ★★★
()
Ответ на: комментарий от izzholtik

ну сделай тест на примере, того что я написал хоть в каком-то подходе. Вот любой пример, например s библиотекой sftp: т е нужно скопировать файл через sftp, протестировав этот метод, не используя сам физический коннект

Jopich1
() автор топика
Последнее исправление: Jopich1 (всего исправлений: 1)
Ответ на: комментарий от izzholtik

Тем, что пистономакаки тестируют всё манкипатчингом.

LamerOk ★★★★★
()
Ответ на: комментарий от Jopich1

а если уметь готовит интерфейсы в го, то там не только просто, но и удобно - создаешь любой объект в тесте, главное чтобы он матчился с инрефейсом (набором методов) и гоняешь в тестах как тебе нужно. правда для этого нужно немного го изучить, не знаю, подходит ли тебе такой метод ))

ergo ★★★
()

либо переписать все на интерфейсы

да

получается везде нужно пихать switch с преобразованиями

нет

Как например я могу протестировать вот такой обьект, замочив ssh.Client ?

Оче условно, лень компелять

//go:generate mockery --name SSHClient
type SSHClient interface {
    // все методы, что ты используешь
    // *ssh.Client автоматически к этому преобразуется где-нибудь снаружи около New
    Something() error
}

type Conn struct {
        SSHClient  SSHClient
}

func (conn *Conn) RunCommands(cmds ...string) (string, error) {
        _ = conn.SSHClient.Something()
        // ...
}

// ...

func TestSshClient(t *testing.T) {
        var mock = new(mocks.SSHClient)
        mock.On("Something").Return(nil).Once()
        var mockClient = Conn{SSHClient: mock}
        // ...
}

Как бонус - твой код перестает быть зависимым от конкретной реализации ssh-клиента.

derlafff ★★★★★
()
Последнее исправление: derlafff (всего исправлений: 6)

тесты

А нах они тебе? Скомпилировалось значит работает.

dnb ★★★★
()
Ответ на: комментарий от izzholtik

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

Что за бред?

1) Что значит «тестировать интерфейс»? В интерфейсе нет кода, только сигнатуры, что ты там тестировать собрался?

2) Моки нужны для удовлетворения зависимостей модуля, если они (зависимости) есть.

3) Реализацию и нужно тестировать как чёрный ящик, без влезания внутрь, потому что в этом и суть модульных тестов — проверить корректность поведения, предоставив возможность менять реализацию, не ломая поведение.

korvin_ ★★★★★
()
Последнее исправление: korvin_ (всего исправлений: 1)
Ответ на: комментарий от Miguel

Ты хоть понимаешь какую чушь сейчас написал?😄 Речь про интерфейсы методов.

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

ergo ★★★
()
Ответ на: комментарий от ergo

Ты хоть понимаешь какую чушь сейчас написал?😄 Речь про интерфейсы методов.

Я понимаю, что интерфейсы методов. Сделай мне вот такой простенький интерфейс без дженериков:

trait Plusable[T] {
  def plus(one: T, another: T): T
}

Потом будем обсуждать, кто какую чушь пишет.

их завезли в 1.18

Угу, и, может, оно даже когда-нибудь из беты выйдет. Тогда будет, что обсуждать. Даже в бете нет вариантности, но это уже, конечно, профессиональная лига.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Я понимаю, что интерфейсы методов.

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

Сделай мне

иди сам делай ))).

зы добро пожаловать в игнор.

ergo ★★★
()
Последнее исправление: ergo (всего исправлений: 2)
Ответ на: комментарий от Miguel

Чего ж вы все так сливаетесь моментально?

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

Ага, только нормальные интерфейсы без дженериков не делаются.

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

из личных наблюдений: низкий порог входа golang может создавать ложную иллюзию его простоты и она часто проявляется у «знатоков», которые мельком почитали о языке и типа «разобрались». а по факту, потом нытье сплошь и рядом про дженерики, как мантру вторящие где надо и где не надо. Дженерики - микроскопическая фича в масштабе любого проекта и ее наличие или отсутсвие не влияет на общий ландшафт проектов. Надеюсь приводить примеры сложных и больших проектов, которые успешно развились и без дженериков, смысла здесь нет, сам догадаешься/найдешь.

ergo ★★★
()
Последнее исправление: ergo (всего исправлений: 2)
Ответ на: комментарий от ergo

тебе подобных сливаем в игнор

«Три дня я гналась за вами, чтобы сказать, как вы мне безразличны»

ты б почитал про golang чуточку больше

Я говорил о нормальных интерфейсах, а не о том куцем огрызке, который имеется в Go.

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

Надеюсь, приводить примеры сложных и больших проектов, которые успешно развились и без Go, смысла здесь нет.

Сам поймёшь, насколько идиотским является подобный аргумент, или разжевать?

Miguel ★★★★★
()

C тестированием все точно так же, как и везде. Go - язык со строгой статической типизацией, потому все типы должны быть объявлены явно, в т.ч. и моки.

type ClientSSH interface {
     RunCommands(cmds ...string) (string, error)
}
 
type MockClientSSH struct {
    MockRunCommands func(cmds ...string) (string, error)
}
 
func(mock *MockClientSSH) RunCommands(cmds ...string) (string, error) {
    return mock.MockRunCommands(cmds...)
}
 
var (
    _ ClientSSH = (*ssh.Client)(nil)
    _ ClientSSH = (*MockClientSSH)(nil)
)

nikolnik ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.