Nhật ký học tập

Ở Day 1, chúng ta đã tạo Unit Test và làm quen với Code Coverage. Ở Day 2, chúng ta tìm hiểu sự khác biệt giữa Line Coverage, Branch Coverage và cách viết test case có ý nghĩa. Trong dự án thực tế, solution thường có nhiều test project. Ví dụ: LibraryManagement.Tests : chứa Unit Test để kiểm tra logic nghiệp vụ. LibraryManagement.IntegrationTests : chứa Integration Test để kiểm tra sự phối hợp giữa các thành phần. Khi chạy từng test project, chúng ta có thể thu được nhiều file kết quả Coverage khác nhau. Nếu muốn xem tổng quan mức độ bao phủ của ứng dụng, chúng ta cần biết cách thu thập, phân biệt và tổng hợp các file kết quả này. Trong bài viết này, chúng ta sẽ sử dụng Coverlet để thu thập Coverage và ReportGenerator để tạo báo cáo HTML dễ đọc. 1. Mục tiêu bài học Sau bài này, bạn sẽ có thể: Hiểu vai trò của nhiều test project trong một solution .NET. Thu thập Coverage riêng cho Unit Test và Integration Test. Giải thích được tại sao thư mục Test...

Ở Day 1, chúng ta đã xây dựng LibraryService , viết unit test và sử dụng Code Coverage để quan sát những dòng code đã được thực thi. Tuy nhiên, một câu hỏi quan trọng vẫn còn: Nếu một dòng code đã chạy, điều đó có nghĩa là chúng ta đã kiểm tra hết logic của dòng code đó chưa? Trong bài này, chúng ta sẽ tìm hiểu ba khái niệm: Line Coverage: Dòng code có được thực thi không? Branch Coverage: Các nhánh của điều kiện có được thực thi không? Assertions: Test có thực sự kiểm tra kết quả mong đợi không? Chúng ta tiếp tục sử dụng ví dụ tính phí trả sách trễ hạn trong hệ thống quản lý thư viện. 1. Nhắc lại logic của LibraryService Ở Day 1, chúng ta đã xây dựng phương thức CalculateLateFee với quy tắc nghiệp vụ: Trả sách đúng hạn: không tính phí. Trễ hạn: tính 5.000 VNĐ cho mỗi ngày trễ. Số ngày trễ âm: dữ liệu không hợp lệ, cần ném ArgumentException . Mã nguồn của LibraryService.cs như sau: namespace LibraryManagement; public class LibraryService { ...

Chạy tất cả Unit Test và nhận kết quả Passed có đồng nghĩa với việc toàn bộ code đã được kiểm tra? Câu trả lời là không. Hãy tưởng tượng bạn vừa hoàn thành một chức năng mới trong ứng dụng .NET. Bạn chạy toàn bộ Unit Test và nhận được kết quả: Passed: 120 Failed: 0 Mọi test đều thành công. Tuy nhiên, có thể một method mới chưa được bất kỳ test nào gọi đến, hoặc một nhánh xử lý quan trọng chưa bao giờ được thực thi. Nếu không có thêm thông tin, chúng ta khó biết được những phần code nào thực sự đã được kiểm tra. Trong bài viết này, chúng ta sẽ tìm hiểu Code Coverage , tạo Coverage Report cho một project .NET và sử dụng báo cáo để tìm những phần code chưa được test. 1. Code Coverage là gì? Code Coverage là một phép đo cho biết phần code có thể thực thi nào đã được chạy trong quá trình thực hiện test. Ví dụ, một ứng dụng có 100 dòng code có thể thực thi. Trong quá trình chạy test, 70 dòng được thực thi. Line Coverage có thể đạt 70%. Con số này giúp chúng ta nhận biết n...

Ở Day 6, chúng ta đã thiết kế database đa ngôn ngữ cho hệ thống quản lý Category, sử dụng ba bảng Languages , Categories và CategoryTranslations . Tuy nhiên, khi ứng dụng phát triển, cấu trúc database thường xuyên thay đổi. Chẳng hạn: Bổ sung cột SortOrder để sắp xếp Category. Tạo bảng CategoryAuditLogs để lưu lịch sử thao tác trên Category. Triển khai phiên bản mới lên môi trường Development, Staging hoặc Production mà không phải tự chạy SQL thủ công trên từng database. Nếu mỗi lần thay đổi chúng ta đều mở SQL Server Management Studio rồi chạy script bằng tay, việc triển khai sẽ dễ sai sót và khó kiểm soát. Trong bài này, chúng ta sẽ tìm hiểu cách sử dụng MigrationPlan và MigrationBase của Umbraco 13 để quản lý các thay đổi schema database theo từng bước. 1. Migration là gì? Migration là một bước thay đổi cấu trúc database có thể được thực thi theo trình tự. Ví dụ, database ban đầu có bảng Categories , sau đó chúng ta cần thêm cột SortOrder , rồi tạo bảng mới đ...

Trong những bài trước, chúng ta đã tìm hiểu các khái niệm cơ bản của React và Next.js. Ở bài này, chúng ta sẽ kết hợp những kiến thức đó để xây dựng một website lịch sử đơn giản, lấy ví dụ về các vị hoàng đế nhà Đường. Mục tiêu không chỉ là tạo một trang hiển thị thông tin, mà còn hiểu cách phát triển từ một trang HTML tĩnh thành một hệ thống có thể lấy nội dung từ CMS và render bằng các React Components. Chúng ta sẽ đi qua các bước: Tạo một trang Next.js tĩnh với Bootstrap. Tách giao diện thành các React Components. Sử dụng dynamic route để xử lý nhiều URL. Lấy nội dung từ một CMS API. Tạo ContentRenderer để ánh xạ nội dung CMS sang React Components. Hiểu luồng render từ CMS đến HTML hiển thị trên trình duyệt. Lưu ý: Các tên như contentHtml , ContentRenderer và CmsPageTemplate trong bài là tên do chúng ta tự đặt để minh họa. Đây không phải API có sẵn của Next.js, React hay Umbraco. JSON của CMS cũng là ví dụ về một API contract do chúng ta thiết kế, khôn...