این پروژه یک نمونه برای آموزش ایجاد نرم افزار به روش مبتنی بر آزمون (TDD) می‌باشد.
لطفا این دایرکتوری را به عنوان یک پروژه در Intellij باز کنید و نیازمندی‌های خواسته شده را به روش TDD پیاده سازی کنید.
در این پروژه یک کلاس User وجود دارد که یک کاربر را نشان می‌دهد. یک کلاس UserRepository داریم که اطلاعات کاربران را در خود نگه می‌دارد و عملیات‌های اضافه کردن، حذف کردن و یا پیدا کردن اطلاعات یک کاربر را انجام می‌دهد و در نهایت یک کلاس به نام UserService داریم که به عنوان سرویس مدیریت کاربران وظیفه‌ی ثبت‌نام کاربر، احراز هویت کاربر و تعدادی سرویس‌های مدیریتی را بر عهده دارد و منطق‌های کسب و کاری در این کلاس پیاده سازی شده است.
| شماره دانشجویی | نام دانشجو |
|---|---|
| ۹۸۱۷۰۸۵۱ | درین ستوده |
| ۹۸۱۷۱۱۳۷ | الهه مرتضویان |
| ۹۸۱۷۰۹۶۸ | فاطمه فتوحی |
- ساخت فایل workflow: این فایل هرگاه یک push یا pull request برای main درست میشود، اجرا میشود و کلیه‌ی تست‌ها را اجرا میکند.
- ساخت مخزن و اعلام محدودیت push به شاحه main: این محدودیت بدین صورت است که امکان push به شاخه main نیازمند ساخت pull request است. حال این pull request برای merge شدن نیازمند برطرف‌‌شدن دو شرط است: ۱) اجرای موفق تست‌ها که توسط workflow اجرا میشوند. ۲) دریافت approval از یک شخص دیگر (سرگروه). البته از آنجا که سرگروه خود نیز در نوشتن کد مشارکت داشت، وی برای merge کردن pull requestهای خودش نیاز به approval ندارد.
- تخته کانبان: تخته کانبان ما دارای workflowهایی. برای حرکت آیتم‌ها در طول خط لوله بصورت خودکار داشت که با شرایط زیر trigger میشدند:
- هر گاه یک ایشو ساخته میشود، آیتم آن در backlog نیز ساخته میشود.
- هر گاه یک ایشو یا pull request بسته یا merge میشد، آیتم آن به done برده میشد.
- علاوه بر این برای هر یک از آیتم‌ها، ایشو میساختیم و برنچ development آن را با نام مناسب حاوی شماره ایشو و عنوان آن میساختیم و پس از از push به remote و ساخت pull request یک کامنت fixes #issue_number اضافه میکردیم و اینگونه فرایند بسته شدن ایشو را به مرج شدن pull request وابسته میکردیم.
