либо в метод, либо в пакет, либо в структуры пакета

но это уже вкусовщина

и все зависит от того, что твой пакет делает

если пакет - неотъемлемая часть приложения, можно его и синглтонами накормить, и свои кастомные зависимости напихать, и вообще

если пакет - библиотека, планируемая для реюза, так делать, конечно, не стоит

ладно спасибо - я убег

чем меньше в ней зависимостей, тем лучше

удачи тебе

для тестов надо везде юзать Dependency Injection

Как мне дб конектор замокать ибо он не подменяется на интерфейс ибо там в методе возвращается транзакция, а вернуть свою подменную транзакцию я не могу ?

Как мне дб конектор замокать ибо он не подменяется на интерфейс ибо там в методе возвращается транзакция, а вернуть свою подменную транзакцию я не могу ?

Не мокать а юзать тестовую-бд+seed?

это уже будет не юнит, а интеграционка

это уже будет не юнит, а интеграционка

А разница?

В интеграционке мне кейсы недоступности базы в разные моменты воссоздать тяжело, из серии начать транзакцию удалось, а коммит нет

В интеграционке мне кейсы недоступности базы в разные моменты воссоздать тяжело, из серии начать транзакцию удалось, а коммит нет

Тебе надо dbconnector оттестировать, причем тут интеграционка?

Не тестируй в нем живость бд - не будет интеграционкой

Кейсы аварийного поведения мне тяжело задавать в тестовой бд, а мне надо проверить что во в любом случае данные не будут утеряны

есть мнение, что это концептуально слабовозможно... доказательства будут лежать больше в математической плоскости

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

в случае "уронить соединение посреди транзакции" вам никто и ничего гарантировать не сможет

ну и, собственно, достаточно странный подход

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

случай обрыва связи посреди транзакции - это ровно второй случай, и он, если честно, со стороны приложения проверке не подлежит, не та область ответственности

Ну мне надо проверить что в случае отказа базы, он в файл запишет данные которые затем можно будет восстановить. Сам клиент коннекта имеет возможность вернуть еррор при выполнение транзакции.

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

Тут не согласен, юнит может проверять не только success путь. Но краевые и аварийные значения.

Ну мне надо проверить что в случае отказа базы, он в файл запишет данные которые затем можно будет восстановить. Сам клиент коннекта имеет возможность вернуть еррор при выполнение транзакции.

Вот тут, если сильно нужно обмазываться "этнически чистым TDD", нужно рефачить реализацию, для проведения тестов.

Ну мне надо проверить что в случае отказа базы, он в файл запишет данные которые затем можно будет восстановить. Сам клиент коннекта имеет возможность вернуть еррор при выполнение транзакции.

соответственно, тестированию подлежат следующие кейсы: 1. коммит прошел - проверяем корректность записанных данных, 2. коммит не прошел - проверяем корректность записи на диск

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

а эмулировать дроп коннекта посредине - это уже патч бд-коннекта с отсутствием гарантии идентичности поведения патченного бд-коннекта и непатченного бд-коннекта

ну, т.е. ересь получается

Ну попытка тестирования в лоб заключалась в

type dbSqlInterface interface { Begin() (transactionInterface, error) Exec(query string, args ...interface{}) (sql.Result, error) Ping() error SetConnMaxLifetime(duration time.Duration) } type transactionInterface interface { Exec(query string, args ...interface{}) (sql.Result, error) Rollback() error Commit() error }

вы аппаратные проблемы все равно на уровне юнит-тестирования не смоделируете

а значит не стоит и пытаться

я эмулирую различный возврат фунций, ошибка не ошибка

выше представленный интерфейс хорошо работает, проверяет то что надо, но реальный конект - Begin() (*sql.Tx, error)

и вот этот один шаг, до решения всех моих проблем, все навернул

хотя и *sql.Tx реализует transactionInterface

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

дело в том, что тестировать проблему с БД между sql.Begin() и sql.Commit() смысла нет

если где-то между произошел дроп соединения с базой, sql.Commit() зафейлится

а все, что вы писали между - откатится

т.е. смысла тестировать ЭТО - нет

Даже если так, я не могу подменить sql.Commit() и проверять ошибку только в нем

на уровне вашего приложения все, что происходит между sql.Tx.Query() и получением *sql.Result - черный ящик

Даже если так, я не могу подменить sql.Commit() и проверять ошибку только в нем

а зачем его подменять?

и зачем проверять в нем ошибку?

вы не на том уровне. На уровне вашего приложения ситуация ошибки драйвера sql, мягко говоря, не существует

если вы, конечно, не пишете драйвер БД

На уровне кода фунция, коммит имеет возможность вернуть ошибку

-> значит этот кейс расматривается как поведение

для того, чтобы она вернула ошибку, можно тупо не поднимать коннект к базе вообще

тогда и пинг, и бегин вернут ошибку

вы можете сделать реализацию интерфейса sql.Tx, которая будет на Commit возвращать тупо ошибку

а остальные - нет

я сделал

в ситуации дропа коннекта к базе вас интересует исключительно один фактор: коммит вернул ошибку

причем детали ошибки вас не интересуют, от слова "вообще"

все верно

посмотрите код выше, Begin() (*sql.Tx, error) а мне для подмены надо сделать Begin() (transactionInterface, error) *sql.Tx реализует transactionInterface

ну так вот в чем вопрос: в чем суть юнит-тестирования

sql.Tx - интерфейс же?

неа

// Tx is an in-progress database transaction. // // A transaction must end with a call to Commit or Rollback. // // After a call to Commit or Rollback, all operations on the // transaction fail with ErrTxDone. // // The statements prepared for a transaction by calling // the transaction's Prepare or Stmt methods are closed // by the call to Commit or Rollback. type Tx struct { db *DB

не, структура, уговорил

из .../go/1.10.1/libexec/src/database/sql/sql.go

ну тогда нужно реализовывать sql-драйвер

ERROR: S client not available

go-sql-driver реализовывает интерфейс же

я всеравно же упрусь в контракт Begin() (*sql.Tx, error)

неа

import( _ "github.com/lib/pq" )

а в lib/pq вот такая вещь: func init() { sql.Register("postgres", &Driver{}) }

а вот уже Driver реализовывает интерфейс

ща поищу, куда там можно вклиниться

https://golang.org/src/database/sql/doc.txt

Буду где то там копать, спасибо

https://golang.org/pkg/database/sql/driver/

во, вот тут написано defines interfaces to be implemented by database drivers as used by package sql

т.е. здесь интерфейсы для всего лоу-левела под sql

вооот же ОНО:

https://golang.org/pkg/database/sql/driver/#Tx

т.е. в драйвере есть driver.Tx, который интерфейс

а в момент sql.Register в сервис-провайдере регистрируется нужный тип

в момент db.Open - создается его инстанс, и дальше sql рулит пулом этих инстансов

а в sql.Tx в момент инициализации соединения суется реализация driver.Tx

они реализовывают один и тот же интерфейс, поэтому там просто подсовываются указатели на методы

Я начинал с sql.DB как с входной точки

т.е. для ваших особо изощренных тестирований - пишите драйвер)

а она юзает sql/driver.Driver под капотом

Который умеет только Open(name string) (Conn, error) ?

Все украдено до нас https://github.com/DATA-DOG/go-sqlmock

а этот Conn - это интерфейс

а скулю нужно рулить пулом этих соединений

Все украдено до нас https://github.com/DATA-DOG/go-sqlmock

верю, должна уже быть реализация этой прелести)

Все украдено до нас https://github.com/DATA-DOG/go-sqlmock

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

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

Наверняка кто-то уже заморачивался с таким

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

собственно, можно взять ЭТО, потом замутить свой тип sql.Tx с sql.Tx'ом унутре, и перекрытым методом Commit()///

тут вот не до конца понял мы же упремся в func (m *testSql) Begin() (*sql.Tx, error) где не сможем вернуть - type testTransaction struct{ sql.Tx }

а зачем тебе возвращать testTransaction?