Вопрос по asp.net, vb.net – Шаги, которые нужно предпринять, чтобы медленно интегрировать юнит-тестирование в проект

6

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

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

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

@FailBoy спасибо за комментарий :) Это определенно вариант. Тем не менее, они, кажется, не слишком заинтересованы в совместной работе. Это просто кажется чертой личности. Они предпочитают просматривать любые изменения, которые я делаю, и задавать вопросы после этого. Я просто не хочу отправлять их в шоковое состояние и должен откатывать все мои изменения кода. Chris
лично, если вы думаете, что можете сделать огромное количество рефакторинга, почему бы не попросить другого студента прийти и посидеть с вами, и по ходу дела он / она может задавать вопросы, и, возможно, у него / нее есть какие-то собственные идеи. Я уверен, что наша индустрия движется быстро, поэтому ваш партнер не столкнется с другими разработчиками, такими же прощающими, как вы. Я добавил это в качестве комментария, потому что он на самом деле не отвечает на ваш вопрос о модульном тестировании. Просто хотел дать вам кое-что еще, чтобы подумать. Удачи! StevenMcD

Ваш Ответ

4   ответа
1

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

Конечно, даже это сложно, когда структура проекта не подходит для тестируемости.

Моя лучшая рекомендация - делать это небольшими шагами.

Начните с создания сборки модульного теста (или проекта или чего-либо еще) без тестов. Затем найдите одну небольшую область кода, которая достаточно хорошо определена и отделена, и напишите несколько модульных тестов для этой области. Заставьте своего кодировщика взглянуть и начните получать «лучшие практики»; работает, как запуск модульных тестов каждый раз, когда любой код проверяется (по возможности автоматически)

Как только у вас это получится, вы можете постепенно начать добавлять больше.

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

Это отличная идея. Однако большая часть функциональности уже реализована. В основном я делаю это для опыта юнит-тестирования, так как ручное тестирование в течение следующих нескольких недель будет довольно сухим. Chris
Судя по всему, это студенческий проект, да? Если вы говорите, что большая часть функциональности выполнена, у вас не останется столько времени, просто сделайте резервную копию и продолжайте вносить изменения. Если ваш партнер не понимает, это не имеет значения, проекты почти закончились в любом случае. Вы получаете свой опыт, и проект все еще в порядке. Напишите в своем письме, что вы узнали, что модульное тестирование лучше всего проводить с самого начала в следующий раз = :)
Это правильно! Вид. Это правительственный кооператив, поэтому дела идут медленно. Пока босс не просмотрит приложение и не сообщит нам, какие изменения он хочет (что может занять месяцы), мы находимся в режиме тестирования. В этот момент система может вывернуться наизнанку. Модульные тесты не только помогут мне учиться, но и, надеюсь, облегчат этот процесс. Я просто не хочу быть неуважительным и оставляю другой кооператив в неведении :) Chris
Ааа ... Если вы ожидаете потенциальных изменений, то модульное тестирование неоценимо. Это позволяет вам быть уверенными в том, что внесенные вами изменения не нарушают других вещей. Я бы поговорил с вашим коллегой и согласовал план между вами. Объясните, почему вы хотите это сделать, и пригласите его на борт. Затем придумайте план для его реализации, даже если план такой же, по крайней мере, у вас есть его согласие.
7

Эффективная работа с устаревшим кодом Майкл Фезерс

Трудно понять, пойдет ли на пользу реализация фабричного шаблона, зависит от того, что делает код :)

+1 Вот краткое изложение того, что вы получите в книге и как создать «шов». что вы можете безопасно проверить:objectmentor.com/resources/articles/…
1

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

После того, как вы проведете удобное количество тестов, проверяющих функциональность вашего проекта на высоком уровне, я начну углубляться в код и, как упоминает Саймон П. Стивенс, работатьslowly, Возьмите (бесплатно!) КопиюРефакторинг! для Visual BasicТаким образом, вы сможете автоматически выполнять некоторые базовые операции рефакторинга, такие как метод извлечения. Вы можете значительно повысить тестируемость, не меняя никакой функциональности, просто разделив большие фрагменты кода на более мелкие, более тестируемые фрагменты.

2

Эффективная работа с устаревшим кодом Michael Feathers (также доступен в Safari, если у вас есть подписка) - отличный ресурс для вашей задачи. Автор определяет унаследованный код как код без юнит-тестов и дает практические руководства поlots консервативных методов, которые необходимы, потому что вы работаете без защитной сетки для проверки кода. Оглавление:

  • Part: I The Mechanics of Change
    • Chapter 1. Changing Software
      • Four Reasons to Change Software
      • Risky Change
    • Chapter 2. Working with Feedback
      • What Is Unit Testing?
      • Higher-Level Testing
      • Test Coverings
      • The Legacy Code Change Algorithm
    • Chapter 3. Sensing and Separation
      • Faking Collaborators
    • Chapter 4. The Seam Model
      • A Huge Sheet of Text
      • Seams
      • Seam Types
    • Chapter 5. Tools
      • Automated Refactoring Tools
      • Mock Objects
      • Unit-Testing Harnesses
      • General Test Harnesses
  • Part: II Changing Software
    • Chapter 6. I Don't Have Much Time and I Have to Change It
      • Sprout Method
      • Sprout Class
      • Wrap Method
      • Wrap Class
      • Summary
    • Chapter 7. It Takes Forever to Make a Change
      • Understanding
      • Lag Time
      • Breaking Dependencies
      • Summary
    • Chapter 8. How Do I Add a Feature?
      • Test-Driven Development (TDD)
      • Programming by Difference
      • Summary
    • Chapter 9. I Can't Get This Class into a Test Harness
      • The Case of the Irritating Parameter
      • The Case of the Hidden Dependency
      • The Case of the Construction Blob
      • The Case of the Irritating Global Dependency
      • The Case of the Horrible Include Dependencies
      • The Case of the Onion Parameter
      • The Case of the Aliased Parameter
    • Chapter 10. I Can't Run This Method in a Test Harness
      • The Case of the Hidden Method
      • The Case of the "Helpful" Language Feature
      • The Case of the Undetectable Side Effect
    • Chapter 11. I Need to Make a Change. What Methods Should I Test?
      • Reasoning About Effects
      • Reasoning Forward
      • Effect Propagation
      • Tools for Effect Reasoning
      • Learning from Effect Analysis
      • Simplifying Effect Sketches
    • Chapter 12. I Need to Make Many Changes in One Area. Do I Have to Break Dependencies for All the Classes Involved?
      • Interception Points
      • Judging Design with Pinch Points
      • Pinch Point Traps
    • Chapter 13. I Need to Make a Change, but I Don't Know What Tests to Write Characterization Tests
      • Characterizing Classes
      • Targeted Testing
      • A Heuristic for Writing Characterization Tests
    • Chapter 14. Dependencies on Libraries Are Killing Me
    • Chapter 15. My Application Is All API Calls
    • Chapter 16. I Don't Understand the Code Well Enough to Change It
      • Notes/Sketching
      • Listing Markup
      • Scratch Refactoring
      • Delete Unused Code
    • Chapter 17. My Application Has No Structure
      • Telling the Story of the System
      • Naked CRC
      • Conversation Scrutiny
    • Chapter 18. My Test Code Is in the Way
      • Class Naming Conventions
      • Test Location
    • Chapter 19. My Project Is Not Object Oriented. How Do I Make Safe Changes?
      • An Easy Case
      • A Hard Case
      • Adding New Behavior
      • Taking Advantage of Object Orientation
      • It's All Object Oriented
    • Chapter 20. This Class Is Too Big and I Don't Want It to Get Any Bigger
      • Seeing Responsibilities
      • Other Techniques
      • Moving Forward
      • After Extract Class
    • Chapter 21. I'm Changing the Same Code All Over the Place
      • First Steps
    • Chapter 22. I Need to Change a Monster Method and I Can't Write Tests for It
      • Varieties of Monsters
      • Tackling Monsters with Automated Refactoring Support
      • The Manual Refactoring Challenge
      • Strategy
    • Chapter 23. How Do I Know That I'm Not Breaking Anything?
      • Hyperaware Editing
      • Single-Goal Editing
      • Preserve Signatures
      • Lean on the Compiler
    • Chapter 24. We Feel Overwhelmed. It Isn't Going to Get Any Better
  • Part: III Dependency-Breaking Techniques
    • Chapter 25. Dependency-Breaking Techniques
      • Adapt Parameter
      • Break Out Method Object
      • Definition Completion
      • Encapsulate Global References
      • Expose Static Method
      • Extract and Override Call
      • Extract and Override Factory Method
      • Extract and Override Getter
      • Extract Implementer
      • Extract Interface
      • Introduce Instance Delegator
      • Introduce Static Setter
      • Link Substitution
      • Parameterize Constructor
      • Parameterize Method
      • Primitivize Parameter
      • Pull Up Feature
      • Push Down Dependency
      • Replace Function with Function Pointer
      • Replace Global Reference with Getter
      • Subclass and Override Method
      • Supersede Instance Variable
      • Template Redefinition
      • Text Redefinition
  • Appendix: Refactoring
    • Extract Method

Похожие вопросы