тестят то, чем будут пользоваться

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

личный опыт как критерий истинности

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

но есть еще методология

и методология говорит нам - тестить надо внешний интерфейс

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

здравый смысл

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

Это ж два разных вида тестирований - ты говоришь про интеграционное

не-не-не

это все те же юнит-тесты

А юнит-тесты вполне можно к внутренней части программы применять, не?

Но тестируя внутренние функции ты тратишь время - реализация может меняться

так здравый смысл или методология, или "стандарт индустрии"?

методология

методология

а какое название у этой методологии?)

TDD

по чистому TDD разрабатывать приходится редко, но unit-тесты - это оттуда

тдд - о том, что начинаешь с написание теста

да

где там про публичность?

а тест пишешь в соответствии с ТЗ

https://en.wikipedia.org/wiki/Black-box_testing

в ТЗ нет ничего про детали реализации - соответственно, и тест на них написать невозможно

аминь

бюлк бокс - уже ближе к делу, и это одна из методик, там не про юниты, а про интеграционные тесты

бюлк бокс - уже ближе к делу, и это одна из методик, там не про юниты, а про интеграционные тесты

хоть бы прочитал

хоть бы прочитал

не прав, почитал

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

значит не внимательно или зэ нью трололо, диалектика йопта

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

каждый вправе сходить с ума как ему захочется

коллеги

значит не внимательно или зэ нью трололо, диалектика йопта

*был не прав

всем привет! один из парметров вызова функции это структура с URL и AcceessTocken, собственно вопрос, а потестировать такую функцию - сейчас она валится из-за неверного AT

а как ты ее потестируешь без сервера

всем привет! один из парметров вызова функции это структура с URL и AcceessTocken, собственно вопрос, а потестировать такую функцию - сейчас она валится из-за неверного AT

- рефакторить, подмокать то место, где проверяется AT, или monkey patching

а как ты ее потестируешь без сервера

httptest.NewServer() сгодится?

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

еще раз - исходя из каких соображений вы пишете тесты на внутренние функции? экспортируемые понятно - их вход и выход прописаны в спеке. а внутренние? сами выдумываете? а смысл?

есть какие-то особенности текущей реализации, о которых внешний контракт не знает, и знать не должен, их тоже, иногда, стоит протестировать

зачем?

если они на контракт не влияют - их м писать-то не надо, не то, что тестировать

еще раз - исходя из каких соображений вы пишете тесты на внутренние функции? экспортируемые понятно - их вход и выход прописаны в спеке. а внутренние? сами выдумываете? а смысл?

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

++

еще раз - исходя из каких соображений вы пишете тесты на внутренние функции? экспортируемые понятно - их вход и выход прописаны в спеке. а внутренние? сами выдумываете? а смысл?

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

нет спеки - нет тестов

вы как дети, ей-богу

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

нет спеки - нет тестов

ага, ты еще скажи "нет ТЗ - нет сервиса"

может просто нечем заняться и let's go writing godlike functions)

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

ага, ты еще скажи "нет ТЗ - нет сервиса"

нет тз - и результат хз

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

С точки зрения спеки там вообще http api на сервисе, но в коде там разделение на пакеты, может только api и тестировать?

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

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

марти макфлай прямо)

дорогая редакция, я худею

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

давайте тогда с начала начнем

зачем вы пишете тесты, тратите на них время и деньги?

зачем вы пишете тесты, тратите на них время и деньги?

Чтобы найти ошибки до попадания в продакшн.

а?!

а как тесты помогают находить ошибки?

ТДД же, пишешь тест, пишешь реализацию

а как тесты помогают находить ошибки?

Они ожидают результат и сверяют его.

а откуда берется эталон, с которым сверять?

От того чего я хочу от этого кода.

а в сам код вы их отчего не заложили?

напоминаю про ТДД

не прав, почитал

This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance

а в сам код вы их отчего не заложили?

Я не один его пишу.

всё интереснее...

This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance

* был не прав* поправился ниже :S в смысле хотел написать "был не прав"

еще раз - исходя из каких соображений вы пишете тесты на внутренние функции? экспортируемые понятно - их вход и выход прописаны в спеке. а внутренние? сами выдумываете? а смысл?

для себя. Пакет может быть сложным внутри. Я что-то поменяю в нём - паблик апи ломается, паблик тест фейлятся. Как мне понять, что именно сломалось внутри,если нет тестов на private функции ?

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

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

Ну смотрите вы код в функции на основании чего выносите?

на основании спеки

на основании спеки

То есть вы весь код в Публичных функциях пишете?

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

почему именно не документированные? может каменты я и напишу для них. Но в принципе сами тесты можно считать документацией иногда

нельзя считать тесты документацией

То есть вы весь код в Публичных функциях пишете?

я тестирую только то, что могу оттестировать. только то, для чего определен эталон