Ну да, а в чем проблема? Или могу взять в экселе вбить, сделать колонку с суммами, выгрузить в csv, загрузить как теорию. Наконец, могу взять AutoFixture, генерить случайные, складывать и сравнивать.
… а можно просто взять работающий и освоить минут за десять.
А за 5 можно и свой написать? :-)
[Fact]
public void PassingTest()
{
Assert.Equal(4, Add(2, 2));
}
Как я уже говорил — тут пишутся не только сам код, но и результат тестирования. а если я возьму более сложный пример — например 125374 + 832748 — будете на калькуляторе считать сколько получится? :-)
Имеет. Во-первых, для любого другого человека подключение стоит намного дороже (документации-то нет), во-вторых, каждую фичу надо дорабатывать.
Ну все при желании запиливается и документируется.
Думаю основой вопрос в каком направлении идти.
Для всех мейнстрим-фреймворков это время меньше, чем время на написание того же для своего фреймворка.
Да, вот это мне нравится больше всего — для «всех». Я знаю что их вагон и маленькая тележка. Можно до конца жизни посвятить себя изучению всех тестовых фреймворков, а можно написать свой и будет работать.
Собственно если вы говорите о мейнстрим-фрейворке, то можете дать линк на хорошую документацию, и как и что пишется?
Ну мне кажется готовый framework или свой framework особо разницы не имеет? Ну т.е. (1) может съесть время, например на допиливание своего frameworkа, но и готовый framework тоже может съёсть время — например на конфигурацию и подключение к buildам.
Хмм… Давайте начнем с начала.
Итак для того что бы запустить unit test
1) нам нужен некий unit test framework и начальный effort что бы его взять в использование
2) надо написать сами unit testы.
Я предполагаю что время ушедшее на развертку (1) пункта намного меньше чем (2). Т.е. если мы сделали (1) каким то образом, то он не съест у нас много времени в отличие от (2).
Мне все таки кажется что проще готовый заменить на мой — но тут это возможно мое субъективное мнение. Я думаю что если скажем писать unit test на библиотеку которая делать 3d подсчёты то наверное проще было бы использовать обычный unit test, но как только библиотека станет сложнее чем 2+2 — то уже проще перейдти на мой подход. Ну а для syncProj-утилиты проблема довольно специфическая — надо было бы проверять синтакс того что генерируется, можно сделать как это делается в premake5, но мне кажется это сложнее.
Но думаю что подход syncProj очень расширяемый — и на базы данных, и на любые файловые операции.
Возможно картинки он не сможет сравнивать, но это уже другой unit test домайн.
А есть здравый смысл и есть каша, которые могут образовываться из мешания между собой субординации, единоначалия, дисциплины, демократии и диктатуры.
Вообще мне кажется самое это то что все в программировании развивается, и техники, и языки, а единственное что не меняется или меняется не координально — это естественный язык (русский или английский). Т.е. язык с Legacy на 2017 лет, без refactoringа и без улучшений.
А язык это та же каша, только программистам проще изъяснятся языком, т.к. они мыслят языком.
А каша в языке дает кашу и в программе.
Но мне кажется мы немного уклоняемся от темы. Т.е. набор слов и язык сам по себе ничем не поможет, вопрос в том что и когда применять.
Если это console output, то я, как программист, знаю что программа должна написать.
Если это .sln или .vcxproj — то обычно я открываю проект Визуал Студией и проверяю что бы она не плювалась, а также при закрытии solution, Visual studio не пыталась бы спасти изменения. (Обычно такое просходит если .sln содержит ошинки, и Visual Studio пытается их исправить).
И что? «Правильные» же все равно должны откуда-то взяться. А после того, как они есть, есть куча готовых модулей для юнит-тестирования, которые их сравнят.
Правильные результаты или результаты тестирования появляются тогда когда ты нажимаешь Yes в том Message boxе что ты получил и результаты спасаются отдельным файлом («одобрено программистом»).
Несмотря на все официальные Style Guides, четкого ответа на все случаи нет.
Очень многие проекты (open source) которые я видел имеют какой то свой стиль кодирования, который бывает иногда очень четко прописан — но с моей точки зрения это больше относится к тому как пишешь — стиль, а это не так важно с точки зрения deadlineов или общей работоспособности кода.
Более важно было бы документировать как код делался. Каким способом, каким подходом. Почему он лучше работает чем остальные варианты.
У меня самого есть дурная привычка указывать комметарием какой scope я закрыл.
Чем это отличается от просто «доработки программы»?
В общем-то я хотел выразиться относительно большие изменения в программе — refactoring как раз подходит.
А если не писать тестовый код вообще, то будет на 100% меньше работы. Правда же, круто?
Да, до полного тестирования мне тоже ещё очень далеко. Дело в том что тестировать можно все связанное с файлами, базами данных, когда дело касается скажем 3d отрисовки или скорости выполнения, то это намного сложнее покрывать тестированием. Но syncProj позволяет тестирование — command line utility как никак.
Когда я пишу результат тестирования, я явно указываю, каким должно быть поведение программы. Я знаю, что оно должно быть таким, и я его фиксирую.
Когда я пишу тестирование, я сначала пишу что программа должна производить, а затем запускаю и проверяю вывела ли она то что я хотел.
Кстати — в syncProj идет сравнение не только по console output — там ещё идет сравнение по тому что сама программа генерирует. т.е. .sln (Solution file format) файлы и .vcxproj (xml, C++ project file format).
Альтернатива этому — это действительно прописывать все возвращаеммые значения, скажем как это сделано в premake.
Тут на самом деле много дельных рекомендаций, и хотел бы их получить в виде документа.
Желательно на английском языке, потому что сам с Финляндии, но если это будет сложно, можете написать и на русском.
Здесь сделал в google документ для свободного editирования:
Минимальный мануал по стилю, зачастую можно ограничится одной фразой: «Код пишется для людей, а не для машины». Стену текста все-равно никто не читает, а так хотя бы будет минимальный чек-лист, по которому реально проверять код перед коммитом.
Я не совсем согласен с этой фразой, но основная идея правильная — документации очень много, и она очень сильно «разбавлена» — т.е. нет хорошего / сильного документа. А здесь вообще сборник кучи книг. Не заставишь ведь всю группу прочитать эти все документы ?!
Это классическое определение. Если вы изменили поведение — это не рефакторинг.
Да, вы кстати правы на wiki страничке так и написано. Но я теперь понял что мне не хватает термина refactoring with external changes.
[Fact]
public void PortShouldBe25() => _sut.Port.Should().Be(25);
Вот это легко понять и поменять. И легко понять тестовый вывод (который будет «Test PortShouldBe25 failed: expected 25, got 20».
Да, но фишка в том что бы пишете и тестовый код _sut.Port и результат тестирования Should().Be(25). Я пишу только тестовый код — т.е. делаю 50% меньше работы чем вы.
> Рефакторинг — это изменение структуры кода без изменения его поведения.
С моей точки зрения ректоринг требуется именно тогда когда добавляешь новые фичи, и хорошо если изменения не затрегивают поведение — но иногда и поведение приходится изменять. Так что я бы не давал такой ограниченной формулировки.
> Ну так тесты — это и есть «отпечатывание всего текстом».
Но заставляет задуматься что печатаешь что бы было понятно что функциональность делает.
Кстати — assert( result == 25 );
заменяется Console.WriteLine( result );
с последующим test result accept. Но естественно если напечаешь 25 — будет не понятно про что речь.
В итоге ты напечатаешь скажем так: Console.WriteLine( "Port number: " + result );
И если в следующей итерации ты решишь поменять номер порта, то мой вариант проще и одобрить и понять что изменилось и почему.
Я сам привык делать refactoring в тот момент когда закладываю новую функциональность и тестирую её помодульно. То что принято называть архитектура или high level design просто результат того что подходишь к одной вещи с нескольких сторон.
Но ещё проблема в том что сторон подхода может быть больше чем 2 (модульно или с программы) — и не факт что в момент написания программист видит все возможные подходы.
Но у меня в основном необходимость refactorить очень маленькая, засчёт разностороннего подхода, но это не всегда относится к чужому коду.
Но для того что бы делать хорошо, нужны инструкции как это делать, хотя бы с примером как делать.
Пока что я не видел хороших инструкций для написания хорошего кода. Т.е. как сделать практичный и хороший design.
Хорошо. Я усложню задачу.
sourceforge.net/p/syncproj/code/HEAD/tree/tests/CsToProjects/TestPerFileConfs
для TestPerFileConfs.cs, я хочу проверить что при данной конфигурации код / скрипт сгенерирует те 12 *accepted* файлов что там лежат?
Вобьешь каждую строчку Assert.Equal?
А за 5 можно и свой написать? :-)
[Fact]
public void PassingTest()
{
Assert.Equal(4, Add(2, 2));
}
Как я уже говорил — тут пишутся не только сам код, но и результат тестирования. а если я возьму более сложный пример — например 125374 + 832748 — будете на калькуляторе считать сколько получится? :-)
Ну все при желании запиливается и документируется.
Думаю основой вопрос в каком направлении идти.
Да, вот это мне нравится больше всего — для «всех». Я знаю что их вагон и маленькая тележка. Можно до конца жизни посвятить себя изучению всех тестовых фреймворков, а можно написать свой и будет работать.
Собственно если вы говорите о мейнстрим-фрейворке, то можете дать линк на хорошую документацию, и как и что пишется?
Итак для того что бы запустить unit test
1) нам нужен некий unit test framework и начальный effort что бы его взять в использование
2) надо написать сами unit testы.
Я предполагаю что время ушедшее на развертку (1) пункта намного меньше чем (2). Т.е. если мы сделали (1) каким то образом, то он не съест у нас много времени в отличие от (2).
На этом этапе вы со мной согласны?
Но думаю что подход syncProj очень расширяемый — и на базы данных, и на любые файловые операции.
Возможно картинки он не сможет сравнивать, но это уже другой unit test домайн.
Revision: 130
Author: tarmopikaro
Date: 16. syyskuuta 2017 10:51:13
Message:
Bugfix: XmlSerializer was causing field reorder by itself, causing weird fails to appear
— Modified: /ProjectTypes.cs
Modified: /tests/ProjectsToCs/TestAllInOne/out_testproj.cs.accepted
Удивительно почему XmlSerializer вообще задает fieldы случайным образом.
Из следующего коммита — TestRunTime.cs — это тот тест что я написал, остальные 11 файлов сгенерированы и просто «одобрены» мною.
Да, готовые есть, но если можно сделать проще — почему бы не сделать?
Ну пока что не реализована, так как делал в свободное время, а не по работе. По работе ситуация с тестированием другая вообще.
Да.
Кстати можно сделать проще:
Console.WriteLine( "Test " + result.ToString()
Что даст Test True или Test False, можно проверить визуально тоже.
У меня была идея что автоматизировать это можно было бы просто без message box promptа — т.е. результат не совпадает — ошибка / майл, и так далее.
Вообще мне кажется самое это то что все в программировании развивается, и техники, и языки, а единственное что не меняется или меняется не координально — это естественный язык (русский или английский). Т.е. язык с Legacy на 2017 лет, без refactoringа и без улучшений.
А язык это та же каша, только программистам проще изъяснятся языком, т.к. они мыслят языком.
А каша в языке дает кашу и в программе.
Но мне кажется мы немного уклоняемся от темы. Т.е. набор слов и язык сам по себе ничем не поможет, вопрос в том что и когда применять.
Если это .sln или .vcxproj — то обычно я открываю проект Визуал Студией и проверяю что бы она не плювалась, а также при закрытии solution, Visual studio не пыталась бы спасти изменения. (Обычно такое просходит если .sln содержит ошинки, и Visual Studio пытается их исправить).
Правильные результаты или результаты тестирования появляются тогда когда ты нажимаешь Yes в том Message boxе что ты получил и результаты спасаются отдельным файлом («одобрено программистом»).
Очень многие проекты (open source) которые я видел имеют какой то свой стиль кодирования, который бывает иногда очень четко прописан — но с моей точки зрения это больше относится к тому как пишешь — стиль, а это не так важно с точки зрения deadlineов или общей работоспособности кода.
Более важно было бы документировать как код делался. Каким способом, каким подходом. Почему он лучше работает чем остальные варианты.
У меня самого есть дурная привычка указывать комметарием какой scope я закрыл.
Знаю что многие будут над этим смеяться, но мне самому удобно, и я сам никому свой стиль не навязываю. :)
В общем-то я хотел выразиться относительно большие изменения в программе — refactoring как раз подходит.
Да, до полного тестирования мне тоже ещё очень далеко. Дело в том что тестировать можно все связанное с файлами, базами данных, когда дело касается скажем 3d отрисовки или скорости выполнения, то это намного сложнее покрывать тестированием. Но syncProj позволяет тестирование — command line utility как никак.
Когда я пишу тестирование, я сначала пишу что программа должна производить, а затем запускаю и проверяю вывела ли она то что я хотел.
Кстати — в syncProj идет сравнение не только по console output — там ещё идет сравнение по тому что сама программа генерирует. т.е. .sln (Solution file format) файлы и .vcxproj (xml, C++ project file format).
Альтернатива этому — это действительно прописывать все возвращаеммые значения, скажем как это сделано в premake.
Желательно на английском языке, потому что сам с Финляндии, но если это будет сложно, можете написать и на русском.
Здесь сделал в google документ для свободного editирования:
docs.google.com/document/d/1c5Aq4DcpKx98MNRi5YI766k6VqwDjxEhFwCSV9WHMts/edit?usp=sharing
Т.е. у всех есть доступ его модифицировать.
Ну и набросал туда кое что от себя, но думаю об этом надо отдельно обговорить, возможно часть текста можно и изменить и модифицировать.
Я не совсем согласен с этой фразой, но основная идея правильная — документации очень много, и она очень сильно «разбавлена» — т.е. нет хорошего / сильного документа. А здесь вообще сборник кучи книг. Не заставишь ведь всю группу прочитать эти все документы ?!
А все новые фишки C++, это тоже не подарок — т.е. драматического улучшения софта из-за них я не вижу.
Лучше давать рекоммендации, и смотреть возьмут ли программисты их в употребление. (т.е. дать им самим подумать и выбрать)
Да, вы кстати правы на wiki страничке так и написано. Но я теперь понял что мне не хватает термина refactoring with external changes.
Да, но фишка в том что бы пишете и тестовый код
_sut.Portи результат тестированияShould().Be(25). Я пишу только тестовый код — т.е. делаю 50% меньше работы чем вы.С моей точки зрения ректоринг требуется именно тогда когда добавляешь новые фичи, и хорошо если изменения не затрегивают поведение — но иногда и поведение приходится изменять. Так что я бы не давал такой ограниченной формулировки.
> Ну так тесты — это и есть «отпечатывание всего текстом».
Но заставляет задуматься что печатаешь что бы было понятно что функциональность делает.
Кстати —
assert( result == 25 );заменяется
Console.WriteLine( result );с последующим test result accept. Но естественно если напечаешь 25 — будет не понятно про что речь.
В итоге ты напечатаешь скажем так:
Console.WriteLine( "Port number: " + result );И если в следующей итерации ты решишь поменять номер порта, то мой вариант проще и одобрить и понять что изменилось и почему.
> Тогда откуда вы знаете, что надо тестировать?
к чему клоните, не совсем понимаю.
Но ещё проблема в том что сторон подхода может быть больше чем 2 (модульно или с программы) — и не факт что в момент написания программист видит все возможные подходы.
Но у меня в основном необходимость refactorить очень маленькая, засчёт разностороннего подхода, но это не всегда относится к чужому коду.
Но для того что бы делать хорошо, нужны инструкции как это делать, хотя бы с примером как делать.
Пока что я не видел хороших инструкций для написания хорошего кода. Т.е. как сделать практичный и хороший design.