Как Вы убеждаете других записать модульные тесты? [закрытый]
Один из способов: вам нужно преобразовать Bitmap в Base64 (String) и отправить этот base64 на сервер.
13 ответов
Существует больше чем одна сторона к тому вопросу, я предполагаю. Я нахожу, что на самом деле убеждение разработчиков к запуску тестов использования не состоит в том, что трудно, потому что список преимуществ использования тестирования часто выступает за себя. Когда это сказало, это - настоящий барьер для фактического начинаний, и я нахожу, что кривая обучения часто немного крута – специально для кодеров новичка. Бросая среды тестирования, тест TDD первый менталитет, и дразня платформу в ком-то, кто еще не доволен ни одним, C#, .NET или программирующий в целом, мог быть просто слишком много для обработки.
Я работаю консультантом, и поэтому я часто должен решать проблему реализации TDD в организации. К счастью достаточно, когда компании нанимают меня, это часто из-за моих экспертных знаний в определенных областях, и поэтому у меня могло бы быть немного преимущества когда дело доходит до привлечения внимания людей. Или возможно это просто, что немного легче для меня как посторонний, чтобы войти новой команде и сказать "Привет! Я попробовал TDD на других проектах, и я знаю, что он работает!" Или возможно это - моя убедительность/упорство?:) Так или иначе мне часто не очень трудно убедить devs начинать писать тесты. Что я нахожу трудно, хотя, должен преподавать их, как записать хорошие модульные тесты. И поскольку Вы указываете в своем вопросе; остаться на справедливом пути.
Но я нашел один метод, что я думаю работы вполне прилично когда дело доходит до обучения поблочного тестирования. Я вел блог об этом здесь, но сущность состоит в том, чтобы сесть и сделать некоторое программирование пары. И делая программирование пары я начинаю писать модульный тест сначала. Таким образом, я показываю им немного, как работа среды тестирования, как я структурирую тесты и часто некоторое использование насмешки. Модульные тесты должны быть простыми, таким образом, в целом, тест должно быть довольно легко понять даже для младшего devs. Худшая часть для объяснения часто является насмешкой, но использование легких для чтения платформ насмешки как Moq помогает много. Затем, когда тест записан (и ничто не компилирует или передачи), я передаю клавиатуру своему коллеге - кодеру так, чтобы он мог реализовать функциональность. Я просто говорю ей/ему; "Заставьте его пойти зеленый!” Затем мы идем дальше к следующему тесту; я пишу тест, 'soon-to-be-test-infected-dev' рядом со мной пишет функциональность.
Теперь, важно понять, что в этой точке dev (s), который Вы преподаете, вероятно, еще не убеждены, что это - правильный способ кодировать. Точка, где большинство devs, кажется, видит (зеленый) свет, - когда тест перестал работать из-за некоторых изменений кода, что они никогда не думали, повредит любую функциональность. Когда тест, который покрывает ту функциональность удары, именно тогда у Вас есть самостоятельно лояльный TDD'er в Вашей команде. Или это - по крайней мере, мой опыт, но как всегда; Ваш пробег будет варьироваться :)
Качество выступает за себя. Если Вы более успешны, чем все остальные, это - все, что необходимо сказать.
Используйте инструмент тестового покрытия. Сделайте это очень видимым. Тем путем все могут легко видеть, сколько кода в каждой области передается, отказавшее и не тестируется.
Затем Вы можете запускаться, культура, где "не протестировано" является знаком плохого кодирования, "отказавший" знак происходящей работы, и "переданный" знак законченного кода.
Это работает лучше всего, если Вы также "тестируете сначала". Затем "непротестированный" становится, "Вы забыли шаг 1".
Конечно, Вам не нужно 100%-е тестовое покрытие. Но одной области имеет 1%-е покрытие, и у другого есть 30%, у Вас есть метрика, для которой область, скорее всего, перестанет работать в производстве.
Подать пример. Если можно получить доказательство, что существует меньше регрессии на протестированной единице, кодируют это в другом месте.
Получение QA и закрытия сделки управления так, чтобы процесс передал под мандат поблочное тестирование.
Будьте готовы помочь другим начать с поблочным тестированием: окажите помощь, предоставьте платформу так, чтобы они могли запустить легко, выполнить вводную презентацию.
Просто необходимо привыкнуть к молитве, "если она не тестируется, работа не сделана!"
Править: Добавить еще некоторую суть к моему остроумному комментарию выше, как кто-то может знать, закончены ли они на самом деле, если они не протестировали свою работу?
Обратите внимание, у Вас будет сражение убедительными другими, если время не будет позволено в оценке для тестирования разработанного кода.
Непосредственное разделение для между усилием для кодирования и который для тестирования, кажется, большое количество.
HTH
удачи,
Ограбить
Дайте поздравление для, каждый пишет больше теста, и приведите к хорошим результатам и покажите лучший другим и попросите, чтобы они привели к тому же или лучшему результату, чем это.
Люди (и процессы) не изменяются без одной или нескольких болевых точек. Таким образом, Вы нуждаетесь к finjd в значительных болевых точках и демонстрируете, как поблочное тестирование могло бы помочь соглашению с ними.
Если Вы не можете найти значительные болевые точки, то поблочное тестирование не может добавить много значения к Вашему текущему процессу.
Поскольку Steve Lott подразумевает, обеспечивая лучшие результаты, чем другие члены команды также помогут. Но без болевых точек, мой опыт состоит в том, что люди не изменятся.
Если разработчики видят, что "успешные" разработчики пишут модульные тесты, и они все еще не делают его затем, я предлагаю, чтобы модульные тесты стали частью формального жизненного цикла разработки.
Например, ни в чем нельзя зарегистрироваться, пока модульный тест не записан и рассмотрен.
Вероятно, reefnet_alex' ответ помогает Вам: действительно ли Поблочное тестирование стоит усилия?
Я думаю, что это был Fowler, который сказал: "Несовершенные тесты, запускаемые часто, намного лучше, чем идеальные тесты, которые никогда не пишутся вообще". Я межпустословлю это как предоставление мне разрешение к тестам записи, где я думаю, что они будут самыми полезными, даже если остальная часть моего покрытия кода будет горестно неполной.
Два пути: убедите менеджера проектов, что поблочное тестирование улучшает качество И экономит время в целом, затем сделайте, чтобы он сделал модульные тесты обязательными.
Или ожидайте уплотнения разработки непосредственно перед важной датой выпуска, где все должны работать сверхурочно и выходные, чтобы закончить последние функции и устранить последние ошибки, только найти, что они только что представили больше ошибок. Затем укажите, что с надлежащими модульными тестами они не должны были бы работать как этот.
Другая ситуация, где модульные тесты можно показать как необходимые, состоит в том, когда выпуск был на самом деле поставлен и, оказывается, содержит серьезную ошибку из-за изменений на последней минуте.
У нас есть среда тестирования, которая включает автоматизированное выполнение набора тестов каждый раз, когда любой фиксирует изменение. Если кто-то фиксирует код, который проваливает тесты, целая команда посылается по электронной почте с ошибками.
Это приводит к представленным ошибкам, исправленным довольно быстро.
Вы упомянули, что Ваш менеджер на борту с модульными тестами. Если это так, разве затем почему он не (она) осуществляющий его? Это не Ваше задание, чтобы заставить всех других следовать вперед или преподавать их и на самом деле, другие разработчики будут, часто снова посылал Вас, при попытке продвинуть его на них. Чтобы заставить Ваших поддерживающих разработчиков писать модульные тесты, менеджер должен подчеркнуть это сильно. Это могло бы закончиться, что часть того акцента является образованием на реализации модульного теста, которая Вы могли бы закончить тем, что были педагогом, и это является большим, но управление им - все.
Если Вы находитесь в среде, где группа решает стиль реализации, то у Вас есть больше мнения в том, как динамичная группа должна быть. Если Вы находитесь в такой среде, и группа не хочет подчеркивать модульные тесты, в то время как Вы делаете, то, возможно, Вы находитесь в неправильной группе/компании.
Я нашел, что "проповедование христианства" или проповедование редко работают. Как другие сказали, сделайте это Ваш путь к Вашему собственному коду, сделайте известным, что Вы делаете это, но не пытаетесь вынудить других сделать это. Если люди спрашивают об этом, являются поддерживающими и полезными. Предложение сделать несколько семинаров ланча или неофициальных шоу собаки и пони. Это сделает намного больше, чем просто жалоба Вашему менеджеру или другим разработчикам, что Вам нелегко писать тесты для кода, который они написали.
Медленный и устойчивый - это не собирается изменяться в течение ночи.
После того как я понял, что в одном месте, где я работал принятие на экспертные оценки, улучшенные чрезвычайно. Моя группа просто сделала это и прекратила пытаться заставить других делать это. В конечном счете люди начали спрашивать s о том, как мы получили часть успеха, который мы сделали. Затем это было легче.