The art of unit testing Chapter 2

Chương 2: Unit test đầu tiên

• Khám phá Unit Testing framework in .NET
• Viết first test với NUnit
• Làm việc với NUnit attributes
• Hiểu 3 ouput types của một unit of work

Khi tôi bắt đầu viết unit test với một unit testing framework thực, có rất ít tài liệu, và framework tôi làm việc không có nhiều ví dụ (Tôi đã code VB5 và 6 vào lúc đó). Nó là thử thách để làm việc với chúng, và tôi bắt đầu viết những poor tests. May mắn thay, thời gian đã thay đổi. Chương này sẽ giúp bạn bắt đầu viết test kể cả khi bạn không biết phải bắt đầu từ đâu. Nó sẽ đưa bạn cách viết unit test thực tế được gọi là NUnit - 1 .NET unit testing framework. Nó là framework ưa thích của tôi bởi vì nó dễ sử dụng, dễ hiểu, có những tính năng tuyệt vời. Có những framework khác, cũng có nhiều tính năng, nhưng Nunit là nơi tôi bắt đầu. Nếu cần, thỉnh thoảng tôi cũng mở rộng ra sử dụng các framework khác. Chúng ta hãy xem NUnit hoạt động nhwthees nào, cú pháp, và cách để chạy nó và lấy feed back khi test fail hoặc pass. Để làm được điều này, tôi sẽ giới thiệu một dự án phần mềm nhỏ mà chúng ta sử dụng xuyên suốt cuốn sách để khám phá kĩ thuật testing và các best practices. Bạn có lẽ sẽ cảm thấy thích NUnit. Nhưng tại sao không sử dụng built-in MSTest framework trong Visual Studio? Câu trả lời bao gồm 2 phần. NUnit có các tính năng tốt hơn MSTesst liên quan đến việc viết unit test và test attributes để giúp dễ dàng maintainable, dễ đọc tests. Trong Visual Studio 2012. built in test runners cho phép test viết trên các frameworks khác, bao gồm NUnit. Để làm được điều này, chỉ cần cài đặt NUnit test adapter cho Visual Studio qua NuGet. (NutGet sẽ được giải thích sau trong chương này). 2.1. Frameworks cho unit testing Manual tests suck. Bạn viết code, bạn chạy nó với debugger, bạn nhất tất cả các phím trên ứng dụng của bạn để nhận được kết quả đúng, và sau đó bạn lặp lại tất cả điều này trong những lần khác khi bạn viết code mới. Và bạn phải nhớ kiểm tra thứ tự code và xem chúng bị ảnh hưởng như thế nào trong code mới. Nhiều thứ hơn phải làm việc bằng tay. Great. Test và Regression testing hoàn toàn bằng tay, lặp lại với cùng hành động như một con khỉ, dễ lỗi và tốn nhiều thời gian, và mọi người dường như ghét phải làm việc trong phát triển phần mềm. Vấn đề này sẽ được giải quyết bằng công cụ. Unit testing framework giúp lập trình viên viết test nhanh hơn với tập APIs, thực thi các test tự động, và xem kết quả các tests dễ dàng hơn. Và chúng ta không bao giờ quên. Hãy lặn sâu hơn. 2.1.1. Unit testing frameworks offer. Cho tới nay, nhiều người đã đọc điều này, các test bạn phải hoàn thành với giưới hạn. Chúng không có cấu trúc. Bạn phải phát minh lại các bánh xe mỗi lần bạn muốn test một tính năng. Một test phải trông như console application, test khác lại sử dụng UI form, và cái khác lại sử dụng web form. Bạn không có thời gian để dành cho việc test, và test không đạt yêu cầu là “dễ dàng implement”. Chúng không thể lặp lại. Không phải bạn và team của bạn có thể chạy các test bạn đã viết trong quá khứ. Điều này phá vỡ yêu cầu rêpatedly. Với một framework, bạn có thể dễ dàng tự động hóa việc viết test có thể lặp lại. Chúng không cover tất cả các phần quan trọng của code. Các test không kiểm tra tất cả vấn để trong code. Nghĩa là tất cả code vói logic trong nó. Bởi vì mỗi đoạn code đều có khả năng bị lỗi. 2.1.2. The xUnit Frameworks. Các unit testing frameworks được gọi là xUnit frameworks bởi vì tên chúng thường bắt đầu với một ký tự của ngôn ngữ đó. CppUnit cho C++. JUnit cho Java, NUnit cho .Net và HUnit cho Haskell. Không phải tất cả chúng đều đặt tên theo cách này, nhưng thường thé. Trong cuốn sách này chúng ta sử dụng Nunit, một .NET unit testing framework giúp dễ dàng để viết tests, chạy và lấy kết quả. 2.2 Giới thiệu về LogAn Project Cuốn sách này sử dụng dự án LogAn cho việc testing, dễ để bwast đầu và bao gồm chỉ một class. Chúng ta sẽ extends project này với các classes mới và tính năng mới. Chúng ta gọi nó là LogAn project viết tắt của “log and notification”. Dưới đây là kịch bản. Công ty bạn có nhiều dự án nội bộ, được sử dụng dụng để monitor các ứng dụng tại trang của khách hàng. Tất cả các sản phẩm sẽ viết log files và đặt chúng vào một thư mục đặc biệt. Các file log này được viết theo một định dạng đặc biệt để công ty bạn có thể đọc được bằng các công cụ của bên thứ 3. Bạn được giao nhiệm vụ tạo ra sản phẩm này, LogAn có thể phân tích các log file và tìm các trường hợp đặc biệt và sự kiện trong chúng. Khi nó tìm được các cases và events, nó sẽ thông báo. Trong sách, tôi sẽ dạy bạn cách viết các test để xác nhận LogAn parsing, nhận dạng event, khả năng notification. Trước khi chúng ta bắt đầu test project của chúng ta, chúng ta sẽ nhìn vào cách viết một unit test với NUnit. bước đầu tiên là phải cài đặt nó. Các mục từ 2.1 -> 2.7 là lúc tôi thực hành, tôi sẽ viết lại nó thời gian tới, có thể là khi hoàn thành các chương và sẽ giới thiệu tới các bạn. 2.8. Tổng kết Trong chương này, chúng ta đã học cách sử dụng NUnit để viếm các tests đơn giản. Bạn đã sử dụng [TestCase], [SetUp], và [TearDown] attributes để đảm bảo test của bạn luôn sử dụng new và untouched state. Bạn đã sử dụng factory methods để nó mỏe maintinable. Bạn cũng sử dụng [Ignore] để bỏ qua các test cần phải fix. Test categories giúp bạn nhóm các test cùng logic hơn là bằng class và namespace, và Assert.Catch() giúp bạn chắc chắn code throws exceptions như mong đợi. Chúng ta cũng xem điều gì sẽ xảy ra khi bạn không phải đối mặt với một single method với một return value và bạn cần phải test state cuối cùng của một đối tượng. Điều này là chưa đầu. Hầu hết test phải deal với các vấn đề coding khó khăn hơn nhiều. Trong các chương tiếp theo sẽ gửi tới bạn các công cụ cơ bản bổ sung cho việc viết unit test. Bạn sẽ cần phải chọn từ các công cụ này khi bạn viết test với các tình huống khó khăn. Cuối cùng hãy ghi nhớ các điểm sau: Thường thường phải có một test class cho một tested class. Một unit test project cho một tested project (bên cạnh integration test prject cho test project), và ít nhất một test method cho một unit of work (cái mà là nhỏ nhất như là một methods hay lớn hơn cho nhiều class). Tên nên đặt clearly sử dụng mô hình sau: [UnitOfWork]_[Scenario] _[ExpectedBehavior]. Sử dụng factory methods để sử dụng lại code cho test của bạn, như là code để khởi tạo đối tượng cho tất cả các test Đừng sử dụng [SetUp] và [TearDown] nếu bạn có thể tránh chúng. Chúng khiến test của bạn less understandable Trong chương tiếp theo, chúng ta sẽ xem các tình huống thực tế, nơi mà code của bạn thực tế hơn. Nó sẽ có phụ thuộc và có các testability problems, và chúng ta sẽ bắt đầu thảo luận về các notion fakes., mocks, và stubs.