دوره عملی TDD و طراحی و پیاده‌سازی معماری نرم‌افزار

دوره عملی TDD و طراحی و پیاده‌سازی معماری نرم‌افزار

محل برگزاری	مدرس	تاریخ شروع اولین جلسه	روز و ساعت	مدت زمان کل دوره	تعداد جلسات	هزینه ثبت‌نام زود هنگام	هزینه ثبت‌نام عادی	ثبت نام در ایوند
آنلاین	مسعود بهرامی	۹ اردیبهشت ۱۴۰۰	۵ شنبه‌ها ساعت ۱۰:۰۰ تا ۱۴:۰۰	۳۲ ساعت	۸ جلسه ۴ ساعته	۱۳۰۰۰۰۰ هزار تومان	۱۶۰۰۰۰ هزار تومان	ثبت ‌نام

 معرفی دوره

---

ما در این دوره که بصورت کاملا عملی و hands-on می‌باشد، به تکنیک TDD نه به عنوان روشی فقط برای نوشتن تست‌های نرم‌افزاری، که به عنوان یکی از مهمترین مکانیزم طراحی و معماری نگاه خواهیم کرد، و ضمن آشنایی با مهمترین اصول و تکنیک‌های TDD، چالش‌های مهم در هر فاز TDD را بررسی کرده و تکنیک‌های مهم و کاربردی عبور از هر فاز را بصورت عملی را فرا خواهیم گرفت، و همچنین فرا خواهیم گرفت که چگونه از TDD هنگامی که هنوز هیچ معماری یا طراحی و فریمورکی وجود ندارد، جهت تفکر، طراحی، تصمیم گیری و پیاده سازی آنها استفاده کنیم، و این موارد را به کمک تست drive کنیم، بصورتی که به پیاده‌سازی برسیم که علاوه بر اینکه کاملا تست پذیر بوده و از تغییرات در نرم‌افزار پشتیبانی می‌کند، به ما کمک می‌کند که به یک سرعت توسعه پایا دست پیدا کنیم. از طرف دیگر همچنین ما برای مهمترین بخش‌های معماری و بیزنس نرم‌افزار خود نیز تست نوشته ایم.

دانشجویان ضمن آشنایی با مهمترین اصول و پرکتیس‌های نوشتن تست نرم‌افزاری، اصول طراحی Emergent and Evolutionary Design را فرا گرفته و با یکی از متداولترین معماری‌های مدرن نرم‌افزاری به نام Ports and Adapters آشنا شده و قادر خواهند بود آن را بر اساس مکانیزم TDD پیاده سازی کنند.

در طول دوره برای یک شرکت/سازمان فرضی دامنه‌ای را مطرح کرده، و تلاش می‌کنیم تا در طول دوره آن را با پیشرانه تست‌های مختلفی که می‌نویسیم از ابتدا پیاده‌سازی کنیم.

چالش‌ها و مسئله‌های مختلف و متنوعی برای در این دوره مطرح می‌شود که هر چالش یک یا چند تکنیک را پوشش می‌دهد و دانشجو با حل کردن و پرکتیس کردن آن می‌تواند بر تکنیک‌ها و اصول مورد اشاره تسلط بهتری پیدا کند.

همچنین در طول دوره چندین جلسه رترو جهت بحث و تبادل نظر و تعمق بیشتر بصورت گروهی برگزار خواهد شد.

 

سرفصل‌های دوره

---

• چرا “نرم”‌افزارهای ما تبدیل به “سخت” افزار می‌شوند؟

• چرا و چه موقع ما نیاز به تغییر در نرم‌افزار خواهیم داشت؟

• مکانیزمهای متداول تغییر در نرم‌افزار

• معرفی انواع سبک‌های معماری نرم‌افزار

  • معماری لایه‌ای
    • معماری nلایه‌
    • معماری Hexagonal
    • معماری Ports and Adapters
    • معماری Clean
  • معماری میکروکرنل
  • معماری مبتنی بر Event
  • الگوی معماری مایکروسرویس‌ها
  • معماری Space-Based

• توسعه نرم‌افزار به عنوان یک فرآیند یادگیری

• معرفی روش‌های کشف دانش و حقایق از دامنه مسئله

  • EventStorming
  • Example Mapping

• بهبود چرخه‌ی بازخورد به عنوان مهمترین ابزار توسعه چابک

• آشنایی با پرکتیسهایی که از تغییرات پشتیبانی می‌کنند

• ایجاد دیکشنری از اصلاحات رایج

  • منظور از Test چیست؟(به عنوان اسم و به عنوان فعل)
  • Assertion
  • Expectation
  • System-Under Test (S.U.T)
  • Test Case-Test Method
  • Unit of Work
  • Test Runner
  • Test Framework
  • Fixture
  • Target Object
  • Dependent-On Component (D.O.C)

• مزیت‌های Self-testing code

• آناتومی Test

  • مقداردهی کردن Context
  • تعریف مکانیزم Expectation
  • Acting – تریگر کردن رفتارهای مورد نظر بر روی SUT
  • Verifying – اعمال مکانیزم‌های تائید نتیجه کار
  • ریست کردن Context(Teardown)

• آشنایی با فلسفه Failed fast

• تصویر بزرگ و جامع از Test-Driven Development

• فرآیند توسعه نرم افزار به روش Test-Driven Development

• حفظ و نگهداری چرخه‌های TDD

  • Red-Green-Refactoring
  • Failing-passing-improving-check-in
  • چرا نباید همزمان دو تا کلاه با هم و بر روی بپوشیم!(بله two-hate!)
  • چگونه در هر زمان فقط یک تصمیم بگیریم؟

• Test به عنوان مهمترین ابزار طراحی

• Test به عنوان Design-session

• Test به عنوان پیشرانه تصیمات طراحی و معماری

• توسعه و پیاده‌سازی معماری بر اساس Test

• الگوهای توسعه نرم افزار به روش Test-Driven Development

• آشنایی با دو رویکرد متداول TDD

  • Chicago school (classicist)
  • London School (Outside-in)

• توسعه به سبکOutside-in

  • فعالیت‌های Iteration صفر
  • Emerging design و architecture به کمک Testها
  • شروع با یک تست پذیرش
  • The Walking Skeleton

• رسیدن و حفظ سرعت توسعه پایا(یکی از مهمترین اصول توسعه چابکی) به کمک TDD

• به تعویق انداختن تصمیمات مهم طراحی و معماری به کمک Test

• Outside-in

• تصمیم گیری و پیاده‌سازی مهمترین جنبه‌های معماری نرم‌افزار بر اساس نیاز و با پیشرانه Test
• آشنایی و پیاده‌سازی متریک‌های Evolutionary Architecture

• Code Kata

  • آشنایی و پیاده‌سازی چند مثال با تکنیک Code Kata به عنوان یک تکنیک بسیار کاربردی جهت پرکتیس کردن اصول و تکنیک‌های TDD

• انواع تست از دیدگاه طراحی و معماری

  • Unit Test
  • Integration Test
  • End-to-End Test
  • Regression Tests
  • Agile Testing Quadrants
  • The Test Pyramid

• Ice-Cream Cone Pattern

• طراحی و پیاده‌سازی API سرویس‌ها با هدایت و پیشرانگی Testها

  • Consumer-Driven Contract(CDC)

• اولویت بندی و انتخاب بهترین و مناسبت‌ترین سناریو جهت نوشتن Test

  • One-step Test
  • Starter Test
  • Explanation
  • Learning Test
  • Regression Test

• الگوها و پرکتیس‌های Testing

  • Child Test
  • Doubling
    • شناسایی و تفکیک انواع وابستگی‌های SUT
    • مشابه سازی وابستگی‌های ورودی و خروجی objectهای تحت Test
      • Stub
        • نقش Stubها در سناریوهای Happy-Path
        • نقش Stubها در سناریوهای Exceptional Path
        • نقش Stubها در Negative Testها
        • پیاده سازی Stub بصورت Hard-Codded
        • پیاده سازی Stub بصورت سفارشی بر اساس سناریو مورد Test
      • Spy
      • Mock
      • Fake
      • Dummy
    • بررسی و ارائه تکنیک‌های ساده‌ای جهت تشخیص زمان مناسب برای Mock کردن یا نکردن Dependencyهای مرتبط با SUT
    • Self-Shunt
    • Log String
    • Crash Test Dummy
    • Broken Test
    • Clean Check-in
    • Humble-Object

• تکنیک‌های مهم جهت پیشرفت از فاز قرمز به سبز در چرخه توسعه TDD

  • Fake it (Till you make It)
  • Triangulate
  • External Fixture
  • Exception Test

• الگوهای طراحی جهت رسیدن به مرحله سبز

  • Command
  • Value Object
  • Null Object
  • Template Pattern
  • Pluggable Object
  • Pluggable Selector
  • Factory Method
  • Imposter
  • Composite
  • Collecting Parameter
  • Singleton

• گام آخر، Refactoring

  • قانون Boy-scot
  • Reconcile Differences
  • Isolate Change
  • Migrate Data
  • Extract Method
  • Inline Method
  • Extract Interface
  • Move Method
  • Method Object
  • Add Parameter
  • Method Parameter to Constructor Parameter

• کار با انواع دیتا در تست

  • Test Data Builders
  • استفاده از Flyweight
  • Combining Builders
  • استفاده از الگوی Factory Method جهت تاکید بر زبان دامین
  • معیارهای رسیدن به Evident Data

• طراحی Testهای مناسبی که به شما کمک می‌کنند به یک طراحی evolutionary دست پیدا کنید

• تکیه بر لاگینگ به عنوان یک ویژگی مهم در طراحی و توسعه مبتنی بر Test

• نگاهی دقیق‌تر به Assertions و Expectations

  • Just enough Dependencies
  • Just enough Many Expectations
  • Explanatory Assertion Messages

• عیب یابی و اشکال زدایی به کمک Test

  • Highlights Detail with Matchers
  • Self-Describing Value
  • Obviously Canned Value
  • Tracer Object
  • Diagnostics are a First-Class Feature

• Design to Fail

• شناسایی انواع رایحه‌های بد که نوشتن تست را مشکل و غیر اقتصادی می‌کند

  • رایحه‌های بد در کد
    • Obscurer test
    • Conditional Test Logic
    • Hard-to-Test Code
    • Test Code Duplication
    • Test Logic in Production
  • رایحه‌های بد در رفتار
    • Assertion Roulette
    • Erratic Test
    • Fragile Test
    • Frequent Debugging
    • Manual Intervention
    • Slow Tests
  • رایحه‌های بد در سطح پروژه
    • Buggy Tests
    • Developers Not Writing Tests
    • High Test Maintenance Cost
    • Production Bugs

• طراحی بخش‌های مشکل معماری با هدایت و کمک Test

  • تکنیک‌ها و الگوهای نوشتن Test برای لایه Persistence
  • طراحی سناریوهای مبتنی بر چند نخی با پیشرانه Test
  • تست کردن سناریوهای مبتنی بر I.O
  • نوشتن Test برای سناریوهایی که نیازمند کار با File System هستند

• طراحی سناریوهای غیرهمزمان(Asynchronous) بر اساس Test

  • Sampling on Listening
  • Two Implementations
  • Runaway Tests
  • Lost Updates
  • Testing That an Action Has No Effect
  • تکنیک‌های تمایز قائل شدن بین کانسرن‌های Synchronization و Assertion
  • Externalize Event Sources

• جلسه رترو (بحث و پاسخ به برخی سوالات مطرح شده توسط کنت بک در مورد TDD)

  • تست‌ها و گام‌های شما در چرخه توسعه TDD تا چه اندازه می‌تواند بزرگ یا کوچک باشد؟
  • برای جه مواردی نیاز به نوشتن تست نداریم؟
  • چه معیارهای برای بررسی اینکه یک تست خوب است یا بد داریم؟
  • TDD چطور می‌تواند به توسعه فریمورک کمک کند؟
  • چه میزان بازخورد نیاز داریم؟
  • چه زمانی باید برخی تست‌ها را پاک کنید؟
  • زبانهای برنامه نویسی و محیط‌های توسعه چگونه بر فرآیند TDD تاثیر می‌گذارند؟
  • آیا می‌تواند یک سیستم بزرگ را بر اساس روش TDD توسعه دهید؟
  • آیا می‌توان توسعه محصول را بر اساس تست‌ها در سطح لایه application پیش برد؟
  • چگونه می‌توانیم به روش توسعه مبتنی بر TDD تغییر ذهنیت بدهیم؟
  • مخاطب TDD چه کسانی یا سازمان‌هایی هستند؟
  • آیا TDD به برخی شرایط اولیه و پیش‌نیازها حساس می‌باشد؟
  • آیا ارتباطی بین TDD و الگوهای طراحی می‌توان برقرار کرد؟
  • چرا TDD می‌تواند یک روش موفق و کارا برای توسعه نرم‌افزار باشد؟

---

 

ابزارها، تکنولوژی‌های و زبان برنامه‌نویسی مورد استفاده در دوره

---

این دوره آموزشی به زبان برنامه‌نویسی و یا تکنولوژی خاصی وابسته نیست و محتوای آن قابل پیاده‌سازی در تمامی زبان‌های برنامه‌نویسی شی‌گرا می‌باشد.

در این دوره برای پیاده‌سازی پروژه‌ها و کد‌ها از زبان برنامه‌نویسی #C و پلت فرم dot net core استفاده می‌کنیم.

برخی از لایبرری‌های مورد استفاده در طول دوره:

• Moq
• FakeItEasy
• NSubstitute
• FluentAssertions
• NFluent
• Ncrunch

---

 

مفید برای:

هایی که دغدغه توسعه یک نرم‌افزار با کیفیت بالا و تست‌پذیر که در مقابل تغییرات در نیازمندیها منعطف می‌باشد را دارند.

پیش نیاز :

برای شرکت در این دوره نیاز می‌باشد که:

در صورتی که با برنامه شی‌گرا و مفاهیم Clean Code آشنا نیستید و تجربه کافی ندارید، پیشنهاد می‌کنیم در دوره‌ی الگوها، اصول و تکنیک‌های Clean Code  مکتب‌خانه DDD شرکت کنید.