да, либы еще таскают скрытый стейт в виде каких-нибудь статических переменных

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

Проект небольшой, если в Conan сейчас не найду её, быстрее на релизе отладиться

IDEA: A series of nonverbal algorithm assembly instructions (Score: 100+) Link: http://j.mp/2EyozRL Comments: http://j.mp/2Ezrlq7

.

В supapro мне не ответили (

Подскажите, где можно почитать про юнит-тесты начиная с основ. Гуглил сам, не смог найти "точку входа" - вся найденная информация предполагает, что я уже что-то знаю

Подскажите, где можно почитать про юнит-тесты начиная с основ. Гуглил сам, не смог найти "точку входа" - вся найденная информация предполагает, что я уже что-то знаю

http://blog.byndyu.ru/2010/01/tdd.html https://habrahabr.ru/post/169381/ https://tproger.ru/translations/unit-tests-purposes/

http://blog.byndyu.ru/2010/01/tdd.html https://habrahabr.ru/post/169381/ https://tproger.ru/translations/unit-tests-purposes/

TDD - это когда нахуй писать код, давайте лучше еще ебанем тестов(с)

TDD - это когда нахуй писать код, давайте лучше еще ебанем тестов(с)

не нарушай процесс обучения

TDD это хороший старт для проектирования API и обзора поляны use case. Возводить их в самоцель - да, зачем? но владеть этой техникой нужно.

всё хорошо в меру, как говорится

TDD - это когда нахуй писать код, давайте лучше еще ебанем тестов(с)

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

http://theiced.livejournal.com/254704.html

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

главное, что этот тезис здесь никто не выдвигал

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

прочитай то, что я написал, столько раз, сколько необходимо, пока не поймешь

во, накидали, спасибо!

прочитай то, что я написал, столько раз, сколько необходимо, пока не поймешь

дело вкуса.

дело вкуса.

нет, какого вкуса, прочитай еще раз

в тдд тесты позволяют тебе СОЗДАТЬ минимально необходимый и достаточный АПИ, потом его реализовать так, как его ожидает увидеть пользователь, ну и потом проверять что он продолжает работать, так как ожидает от него пользователь

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

вкус тут не при чём

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

мкей, понятно

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

если ты никогда не разрабатывал АПИ интерфейс для другой программы, то и понятно что а) и б)

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

ok, посоветуй тогда @narical с вершины своего опыта истинно верный путь. пока я не увидел от тебя, чтобы ты что-то предложил.

> истинно-верный путь. Программирование - это не церковь. Тут не единственно правильного решения

> истинно-верный путь. Программирование - это не церковь. Тут не единственно правильного решения

ну тогда ознакомление с TDD ни к чему плохому привести не может. напротив, откроет хороший подход к проектированию API. ну а дальше свой опыт уже введет свою шкалу мер и весов.

ну тогда ознакомление с TDD ни к чему плохому привести не может. напротив, откроет хороший подход к проектированию API. ну а дальше свой опыт уже введет свою шкалу мер и весов.

олегу лучше тебя знать, что полезно а что нет

Я сам разберусь, мне пока "предмет исследования" непонятен. Начиная с того, что делаю я свой проектик - имеет ли смысл делать тесты для него, и КАК ИМЕННО это делается.

Я сам разберусь, мне пока "предмет исследования" непонятен. Начиная с того, что делаю я свой проектик - имеет ли смысл делать тесты для него, и КАК ИМЕННО это делается.

смотря какой проектик, на определенных масштабах разные виды тестов бывают бессмысленными

Пока я регулярно собираю, запускаю и тыкаю всячески кнопочки. Иногда вдруг падает.

Пока я регулярно собираю, запускаю и тыкаю всячески кнопочки. Иногда вдруг падает.

для тыкания кнопочек есть автоматизированные тулы типа selenium и roboelectric

Я сам разберусь, мне пока "предмет исследования" непонятен. Начиная с того, что делаю я свой проектик - имеет ли смысл делать тесты для него, и КАК ИМЕННО это делается.

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

Я сам разберусь, мне пока "предмет исследования" непонятен. Начиная с того, что делаю я свой проектик - имеет ли смысл делать тесты для него, и КАК ИМЕННО это делается.

имеет, чтобы научиться писать тесты и вообще понять что и зачем

Пока я регулярно собираю, запускаю и тыкаю всячески кнопочки. Иногда вдруг падает.

Ну вот, скоро тестами обмажешь. Селениум там какой-нибудь

Пока я регулярно собираю, запускаю и тыкаю всячески кнопочки. Иногда вдруг падает.

это уже интеграционный и енд-ту-енд тест, до этого еще два слоя

написание тестов еще приучает писать чистый и тестируемый код, а не херню с кучей скрытого состояния

(Олегу это ясен пень не нужно)

Ты такой смишной

Первое, кстати, что мешало мне понять - само понятие unit. Я раньше считал что это класс. Вот к слову из книги о которой говорили выше, я о них и узнал.

Поясню для Беркуса: тесты - это хорошо. Но TDD - это уж очень дело задачи и требований. Так что начинать знакомство с unit-tests с TDD - это извращение, имхо. Тем более, судя по задаче человека - ему лучше всего просто осваивать тесты для начала.

Поясню для Беркуса: тесты - это хорошо. Но TDD - это уж очень дело задачи и требований. Так что начинать знакомство с unit-tests с TDD - это извращение, имхо. Тем более, судя по задаче человека - ему лучше всего просто осваивать тесты для начала.

так и запишем, к тестированию претензий не имеет 😊

Короч вот о чем я говорил - открываем "юнит-тестирование для чайников", но вместо точки входа имеем целые абзацы на марсианском языке: Вне зависимости от платформы не стоит писать велосипеды. Я видел много проектов, в которых автоматические тесты (в основном, не юнит, а приемочные) запускались из консольного приложения. Не надо этого делать, все уже сделано за вас. Уделите чуть больше внимания обзору фреймворков. Например, многие .NET разработчики используют MsTest только потому, что он входит в поставку студии. Мне гораздо больше по душе NUnit. Он не создает лишних папок с результатами тестов и имеет поддержку параметризированного тестирования. Я могу так же легко запускать мои тесты на NUnit с помощью Решарпера. Кому-то понравится элегантность xUnit’а: конструктор вместо атрибутов инициализации, реализация IDisposable как TearDown.

Там вся статья в принципе написана из расчета, что читатель уже умеет писать тесты

Там вся статья в принципе написана из расчета, что читатель уже умеет писать тесты

ну значит это не та статья которая тебе нужна

Там вся статья в принципе написана из расчета, что читатель уже умеет писать тесты

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

нужна "точка входа"

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

теоретически все просто

но когда читаю такие вот статьи, то одни вопросы возникают

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

взять какой-то тест фреймворк (Catch2, boost.test любой) и по его туториалу написать первый тест

http://cppunit.sourceforge.net/doc/cvs/cppunit_cookbook.html

я на этом осваивал

то есть вот реально грамотный совет - начинать с фреймворка?

это будет что-то типа BOOST_AUTO_TEST(firstTest) { BOOST_TEST(value == 1) }

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

напиши функцию разоворота строки. А потом проверь, что она работает на: 1) На случае нечётного кол-ва символов 2) Чётного кол-ва 3) Пустой строки Код скинь сюда

то есть вот реально грамотный совет - начинать с фреймворка?

напиши сначала своими руками

@narical давай я попробую тебе ее дать: написал ты функцию: int add(int a, int b) {return a + b;} а теперь ты создаешь набор утверждений: assert(5 == add(3, 2)); assert(0 == add(-1, 1)); вот это и есть процесс написания теста - набор утверждений относительно твоей функциональности

то есть вот реально грамотный совет - начинать с фреймворка?

ну там уже все настроено для тебя, можно переходить собсно к тестам

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

как работает?

у меня есть игровой класс

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

на нижнем уровне у тебя есть набор утверждений

ну хотя это уже итеграционное тестирование, да

тест проверяет что все утверждения выполняются

ВСЁ

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

я написал тебе выше

где мне его писать? как его собирать?

это часть проекта?

берешь и проверяешь что при заданных аргументах тестируемая функция возвращает ожидаемый ответ

я написал - просто сделай то, что я тебя попросил

отдельные исполняемые файлы?

часть проекта, писать в файле с тестами, собирать билдсистемой

так, ага

запускать ctest . если ты пользуешься цмейком

это один файл с тестами?

ибо в цмейке встроена поддержка тестов изначально

и этим он ТОЖЕ хорош

что бы там Олег ни утверждал