Кто-либо использовал Поблочное тестирование в качестве способа изучить программирование?

Как можно раньше. Все мои препятствия при внедрении TDD были связаны с тем, что мне пришлось отказаться от старых привычек и изменить свой образ мышления. Если бы я мог с самого начала мыслить в терминах TDD, я нашел бы все это намного проще.

Тестирование в целом следует преподавать как часть первого курса программирования, ИМО. Модульное тестирование не обязательно является чем-то, что я бы поставил в самом начале, поскольку идея о том, что является или не является «модулем», может легко стать частью семантики и философии. Определение типов тестов как модульных я смог увидеть на втором или третьем курсе. Конечно, я не помню, как изучал модульное тестирование в университете, поэтому почему-то это не вошло в учебную программу, в которой я учился в школе еще в 90-х.

TDD как философию, вероятно, можно было бы использовать вскоре после получения основных идей тестирования. Я не уверен, что хотел бы проходить всевозможные тесты с людьми, которые понятия не имеют, как выглядит код. Как только кто-то освоит основы программирования, тесты станут полезным способом показать: «Да,

Конечно, это очень субъективный вопрос, но я думаю, что мы определенно можем поставить на него раннее ограничение. Я бы сказал, что не раньше, чем операции фреймворка модульного тестирования перестанут казаться волшебством. Итак, в Java, с JUnit, вам нужно сначала понять исключения, методы, возвращаемые значения, параметры, базовые операторы и тому подобное.

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

Я думаю, что парадигма (сдвиг в мышлении), необходимая для работы с TDD (или хочу, чтобы работала с TDD), заключается в том, что это обосновано «целостным» взглядом на то, где программисты тратят время и добавляют ценность. Специалисты в области Agile / Scrum обучаются видеть, что часть кода имеет положительную ценность (и считается «выполненной») только тогда, когда она правильно достигает своей цели (преобразования чего-либо и т. Д.). Это потому, что мы только обманываем себя относительно ценности (приемлемости), если она не верна.

Определение структуры теста сначала определяет цель кодирования и то, где она может пойти не так (крайний и отрицательный тестовые примеры). Кроме того, проверка того, достигнута ли цель, автоматизирована.

Мы говорим о новичке или программисте, изучающем новый язык? Если второе - сразу скажу. Почему? Поскольку лучший способ учиться - это программировать, а если вы пишете код, вам следует тестировать. Однако тому, кто не разбирается в программировании, вероятно, сначала следует изучить основы программирования

TDD makes you think a lot more before coding - something I used to lack in the beginning of my career. I used to get up and running in the IDE and start typing away - code and fix as they say.

If I had used unit testing and TDD earlier in my development as a programmer, then I firmly believe I could have produced better quality code sooner (Not that my code at that time was total crap mind :)

В качестве примечания, TDD и / или модульное тестирование могут быть очень поздно в обучении. процесс. Даже опытные программисты могут получить пользу от обучающих тестов , когда начнут работать с новым языком или новым API.

Кент Бек рекомендует это под названием « Learning test » в «Красной полосе». шаблонов »в разработке через тестирование: на примере.

Вместо того, чтобы просто использовать новый метод или новый класс, напишем небольшой тест это подтверждает, что API работает так, как ожидалось.

Подобным образом Майк Кларк написал набор из 400+ тестов, изучая Ruby .

Написание обучающих тестов - увлекательный способ тыкай и подталкивай любой новый язык или API. И с каждым написанным вами тестом вы инвестирование в исполняемые знания base.

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

Especially considering the context - Python unit tests are very easy to write and require very little understanding - I'd say go for it and blanket your understanding and explorations with tests.

After you have been doing this for a while, include a review stage where you go back and read your earlier tests and see how you would have rewritten them with your current understanding. That's what comments are for - write questions and review notes to yourself in the docstrings inside each test definition.

With such an incremental approach, using version control will help with reviewing and I recommend it highly, in particular because you will be able to see a history of your changes from the version control logs and thus more self-encouragement with your visible progress. I recommend git and using either the built-in gitgui or GitX on Macinosh.

As a very experienced professional, I predate the unit testing concept but I've certainly used lots of small tests as a way to learn new libraries and languages.

Я думаю ваша концепция модульного тестирования неверна . С технической точки зрения, «Модульное тестирование» - это метод проверки и валидации программного обеспечения, при котором программист проверяет, подходят ли отдельные единицы исходного кода для использования. Единица - это самая маленькая тестируемая часть приложения. В процедурном программировании единицей может быть отдельная функция или процедура, а в объектно-ориентированном программировании это может быть метод класса.

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

. С другой стороны, Модульное тестирование - это всего лишь одна из методологий раздела «Тестирование программного обеспечения». Это не часть начала разработки программного обеспечения. Оно выполняется в конце, когда была создана довольно большая программа, и чтобы гарантировать, что каждая часть (то есть меньшие единицы, такие как функции , процедуры, методы класса и т. д.) работают правильно. Модульное тестирование не может использоваться для разработки программного обеспечения, потому что в конце, если модульное тестирование приводит к «какой-либо одной части имеет ошибку», это определенно означает, что все программное обеспечение ошибочно, а если модульное тестирование говорит «все части не имеют ошибок, это не так». «Это означает, что все программное обеспечение не содержит ошибок», потому что при интеграции этих частей может быть некоторая ошибка, или нельзя ожидать, что модульное тестирование обнаружит все ошибки в программе: невозможно оценить каждый путь выполнения во всех программах, кроме самых тривиальных. То же верно и для модульного тестирования. Кроме того, модульное тестирование по определению проверяет только функциональность самих модулей. Следовательно, он не будет обнаруживать ошибки интеграции или более широкие ошибки системного уровня (например, функции, выполняемые несколькими модулями, или нефункциональные области тестирования, такие как производительность). Модульное тестирование должно проводиться вместе с другими действиями по тестированию программного обеспечения. Как и все формы тестирования программного обеспечения, модульные тесты могут показать только наличие ошибок; они не могут показать отсутствие ошибок.

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

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

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

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

Надеюсь, теперь вы лучше понимаете термин «модульное тестирование». А вы хотите научиться «прототипированию программного обеспечения». Что касается обучения, вы можете выбрать любой путь, т.е. a) Read a lot of programs before you code one b) Just read few basics of any programming language and start creating simpler programs and later on make them complex with your increased knowledge.

Option (a) takes less time to get you on the expert's way and also there is a less chance to adopt wrong practices that you may develop during "Self learning programming"

Option (b) takes more time to get you on the expert's way but may be you may devise your own style of programming and may be it becomes as good as (if not better) other expert's style of programming.

I RECOMMEND DON'T CHOOSE ONLY ONE WAY of the above mentioned options (a) or (b). USE A MIX OF BOTH AND START WITH OPTION (a).

Happy Programming! Welcome to the Crazy Community!