Nhật ký học tập

Bài đăng

Các bài đăng gần đây

Dọn ổ C: Chuyển Playwright Browsers sang ổ D chỉ với 1 biến môi trường

Nếu dùng Playwright một thời gian, kiểu gì cũng có ngày bạn nhìn lại ổ C rồi giật mình: thư mục AppData phình to bất thường. Thủ phạm quen thuộc chính là Playwright. Mặc định nó sẽ tải toàn bộ Chromium, Firefox và WebKit về đường dẫn: C:\Users\<username>\AppData\Local\ms-playwright Mỗi lần nâng cấp thư viện, Playwright lại kéo thêm một dàn browser binaries mới. Vài ba dự án cùng chạy là ổ C dễ dàng "bốc hơi" từ 5 đến 10 GB. Để dứt điểm vấn đề này, bạn chỉ cần chuyển toàn bộ browser sang ổ D qua các bước dưới đây. Cơ chế hoạt động flowchart TD A[Mặc định: Ổ C] -->|Chiếm 5-10 GB AppData| B[C:\Users\...\ms-playwright] C[Biến môi trường: PLAYWRIGHT_BROWSERS_PATH] -->|Trỏ sang Ổ D| D[D:\PlaywrightBrowsers] D --> E[chromium-xxxx] D --> F[firefox-xxxx] D --> G[webkit-xxxx] Bước 1: Tạo thư mục lưu trữ trên ổ D Tạo sẵn một thư mục riêng để chứa toàn bộ browser binaries, ví dụ: D...

Test Coverage trong .NET: Tổng hợp Coverage từ nhiều Test Project - Day 3

Ở 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...

Test Coverage in .NET: Line Coverage và Branch Coverage khác nhau thế nào? - Day 2

Ở 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 { ...

Test Coverage in .NET: Run All Tests không có nghĩa là Code đã được Test - Day 1

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...

Umbraco 13: Quản lý thay đổi Database với MigrationPlan và NPoco - Day 7

Ở 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 đ...