Unit Test Dùng Để Làm Gì Và Kinh Nghiệm Viết Unit Test Tốt Nhất

--- Bài mới hơn ---

  • Hướng Dẫn Viết Unit Test Cho Laravel (P2)
  • Viết Unit Test Trong C# Với Nunit
  • Unit Test Cho Nodejs Với Mocha
  • Hướng Dẫn Viết Unit Test Cho Laravel (P3)
  • Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?
  • Đâu là sự khác biệt giữa một unit test tốt và dở? Làm thế nào để bạn có thể viết được các unit test tốt? Điều này không được rõ ràng lắm. Thậm chí nếu bạn là một lập trình viên tài ba với nhiều thập niên kinh nghiệm, kiến thức và thói quen hiện tại của bạn sẽ không tự động giúp bạn viết ra được các unit test tốt, bởi vì nó là một dạng khác của lập trình và hầu hết mọi người bắt đầu với giả định sai lầm vô ích về những gì mà các unit test cần phải đạt được.

    Hầu hết các unit test mà tôi thấy là khá vô ích. Tôi không đổ lỗi cho các nhà phát triển phần mềm: thông thường, anh ta hoặc cô ta khi được yêu cầu viết unit test, thì họ sẽ cài đặt NUnit và bắt đầu tung ra một loạt các API của NUnit) là vi phạm quy tắc độc lập này. Quá trình test có thể hiển thị nhiều thất bại nếu một cái gì đó thay đổi, nhưng nó vẫn chỉ có một phương pháp test để duy trì, vì vậy điều đó cũng tốt.)

    Đừng sử dụng unit test trong phần thiết lập cấu hình

    Theo định nghĩa, các thiết lập cấu hình của bạn không phải là một phần của bất kỳ unit code nào (đó là lý do tại sao bạn trích xuất các thiết lập ra khỏi code của unit của bạn). Ngay cả khi bạn có thể viết một unit test để kiểm tra cấu hình của mình, nó chỉ đơn thuần buộc bạn phải xác định cấu hình tương tự tại một vị trí dự phòng bổ sung. Xin chúc mừng: nó chứng tỏ rằng bạn có thể copy và paste!

    Cá nhân tôi coi việc sử dụng những thứ như các filter trong chúng tôi MVC như là cấu hình. Các filter như là các cấu hình tùy chọn gắn vào trong code của bạn. Bằng mọi cách viết một kiểm thử tích hợp (integration test) cho các hành vi bên ngoài-quan sát được (externally-observable), nhưng nó là vô nghĩa để thử unit testing cho sự hiện diện của các thuộc tính của filter trong mã nguồn của bạn – một lần nữa nó chỉ chứng tỏ rằng bạn có thể copy và paste. Điều đó không giúp bạn thiết kế bất cứ điều gì, và nó sẽ chẳng bao giờ phát hiện bất kỳ lỗi nào cả.

    Đặt tên các unit test của bạn một cách rõ ràng và nhất quán

    Nếu bạn đang kiểm thử action Purchase của ProductController hành động như thế nào khi hết hàng trong kho (stock is zero), sau đó có thể có một lớp test fixture được gọi là PurchasingTests cùng với một unit test gọi là ProductPurchaseAction_IfStockIsZero_RendersOutOfStockView(). Cái tên này mô tả đối tượng (action Purchase của ProductController), kịch bản (hết hàng trong kho), và kết quả (hiển thị trên view là “hết hàng”). Tôi không biết liệu có một cái tên cho mô hình đặt tên này hay không, mặc dù tôi biết nhiều người khác cũng làm theo cách này.

    Tránh sử dụng những tên unit test không rõ nghĩa như Purchase() hoặc OutOfStock(). Việc bảo trì sẽ rất khó khăn nếu bạn không biết là mình đang cố duy trì cái gì.

    Kết luận

    Không còn nghi ngờ gì nữa, unit testing có thể làm tăng đáng kể chất lượng dự án của bạn. Nhiều người trong ngành cho rằng việc có thêm bất kỳ unit test thì tốt hơn là không có gì, nhưng tôi không đồng tình với quan điểm đó: một bộ test có thể là một tài sản tuyệt vời, hoặc nó có thể là một gánh nặng rất lớn mà không mang lại giá trị gì nhiều. Nó phụ thuộc vào chất lượng của những test này, mà dường như được xác định bởi mức độ các nhà phát triển hiểu rõ những mục tiêu và nguyên tắc của unit testing.

    --- Bài cũ hơn ---

  • Unit Test Là Gì? Giới Thiệu Về Unit Test Và Ví Dụ
  • Làm Sao Để Mô Tả Phần Lợi Ích (Why) Trong User Story
  • Cách Viết User Stories: Trải Nghiệm Phương Pháp Agile
  • User Story Là Gì Và Tiêu Chí Chấp Nhận
  • Để Tạo Ra Những User Story Tốt Nhất
  • Phần 1: Cách Viết Unit Test Trong C#

    --- Bài mới hơn ---

  • Hướng Dẫn Về Phong Cách Viết
  • Hướng Dẫn Viết Thư Cuộc Thi Viết Thư Upu Quốc Tế Lần Thứ 50
  • Gợi Ý Về Chủ Đề Cuộc Thi Viết Thư Quốc Tế Upu Lần Thứ 46
  • Làm Sao Giỏi Văn, Giỏi Viết Lẫn Lách…
  • Trường Tiểu Học Lê Thị Hồng Gấm
  • Bài viết sẽ hướng dẫn các bạn từng bước tạo, chạy và tối ưu Unit tests sử dụng Microsoft unit test framework. Chúng ta sẽ bắt với 1 project C# đang trong giai đoạn phát triển, chúng ra sẽ tạo các tests và chạy nó, xem xét kết quả.

    Yêu cầu

    – Visual Studio 2022

    – xem code ví dụ tại Sample Project for Creating Unit Tests.

    1.Tạo một unit test project

    Bạn cần tạo trước project với code ví dụ tại Sample Project for Creating Unit Tests.

    1. Trong New Project dialog box, chọn Installed, chọn Visual C#, và chọn Test.
    2. trong danh sách, chọn Unit Test Project.
    3. Trong Name box, đặt tên là BankTest, và chọn OK.The BankTests project is added to the the Bank solution.
    4. Trong BankTests project, add reference đến BankAccount (project bạn muốn viết Unit test) trong solution.

     

     

    2.Tạo một test class

    Trong test project bạn đổi tên chúng tôi thành chúng tôi Sau đó bạn mở file chúng tôi và bạn sẽ thấy code bên dưới

    // unit test code using System; using Microsoft.VisualStudio.TestTools.UnitTesting; namespace BankTests { public void TestMethod1() { } } }

    Yêu cầu của một Test class

    • attribute .

     

    3.Tạo test method đầu tiên

     

    Chúng ta sẽ viết unit test cho Debit method trong class BankAccount . .

    Bằng các phân tích, chúng ta thấy được Debit method có  ít nhất 3 trường hợp cần test:

    1. Method ném ra Exception ArgumentOutOfRangeException Nếu số tiền rút lớn hơn số tiền có trong tài khoản.
    2. Method ném ra Exception  ArgumentOutOfRangeException nếu số tiền rút nhỏ hơn 0.
    3. Nếu việc kiểm tra 1 và 2 là đúng, method sẽ trừ số tiền rút ra khỏi tài khoản.

    Trong thử nghiệm đầu tiên của chúng ta, chúng ta xác minh bằng một số tiền hợp lệ (số ít hơn số dư tài khoản và lớn hơn số không) và trả về một số tiền chúng ta đã xác định trước.

    Tạo một test method

    Chúng ta cập nhật file chúng tôi như bên dưới

    using Microsoft.VisualStudio.TestTools.UnitTesting; using BankAccountNS; namespace BankTests { public void Debit_WithValidAmount_UpdatesBalance() { // arrange double beginningBalance = 11.99; double debitAmount = 4.55; double expected = 7.44; BankAccount account = new BankAccount("Mr. Bryan Walton", beginningBalance); // act account.Debit(debitAmount); // assert double actual = account.Balance; Assert.AreEqual(expected, actual, 0.001, "Account not debited correctly"); } } }

    Trong test method Debit_WithValidAmount_UpdatesBalance chúng ta giả định tai khoản có beginningBalance = 11.99 và chúng ta sẽ rút debitAmount = 4.55 vậy số tiền còn lại phải là expected = 7.44. Chúng ta sử dụng AreEqual method để kiểm chứng tài khoản còn lại đúng với mong muốn.

    Yêu cầu của Test method

    • Test method phải có attribute [TestMethod].
    • Test method phải return void.
    • Test method không có tham số.

     

    4.Build và run test

    1. Trong Build menu, chọn Build Solution. Nếu không có lỗi, Test Explorer window sẽ xuất hiện(bên trái), Debit_WithValidAmount_UpdatesBalance sẽ được liệt kê trong nhóm Not Run Tests.
    2. Chọn Run All để run test. Trong Test Explorer status bar bắt đầu run. sau khi kết thúc test, thanh bar sẽ chuyển sang màu xanh lá test methods pass, hoặc đỏ nếu tests fail.

     

    5.Sửa lỗi và chạy lại Test

     

    Chúng ta cần kiểm tra lại method Debit.

    Nguyên nhân lỗi

    m_balance += amount;

    Cần sửa lại thành

    m_balance -= amount;

    Chạy lại test

    Trong Test Explorer, chọn Run All để chạy lại hết các test method. Thanh trạng thái chuyển sanh màu xanh lá, và test được chuyển sang Passed Tests group.

     

    Phần 2: Sử dụng Unit Test để cải thiện code

     

    Bài viết Phần 1: Cách viết Unit Test trong C Sharp được dịch từ

    https://msdn.microsoft.com/en-us/library/ms182532.aspx#BKMK_Create_a_unit_test_project

    --- Bài cũ hơn ---

  • Cách Luyện Viết Chữ Thư Pháp Đẹp – Có Kèm Bảng Chữ Cái
  • Thứ Tự Tên Tiếng Anh Nên Viết Thế Nào? – Du Học Anh
  • Hướng Dẫn Khai Sơ Yếu Lý Lịch Tự Thuật
  • Số Đếm Tiếng Anh: Cách Đọc, Viết Và Sử Dụng Đúng
  • Hướng Dẫn Viết Bài Review Sản Phẩm Trên Blog Hiệu Quả
  • Unit Test Là Gì? 10 Frameworks Unit Test Cho Javascript

    --- Bài mới hơn ---

  • Hướng Dẫn Viết Unit Test Trong Angular
  • Hướng Dẫn Viết Unit Test Trong React
  • Unit Test Trong C# Với Nunit Và Moq
  • Unit Testing Ứng Dụng C# Dùng .net Core Và Visual Studio Code
  • 【Hướng Dẫn】 Cách Viết Thư Upu Lần Thứ 50
  • Thông thường khi làm một dự án web lớn thì nó sẽ được chia thành nhiều phần nhỏ để dễ dàng phát triển cũng như chỉnh sửa. Unit test có nhiệm vụ giúp bạn thực hiện kiểm tra các chức năng đó có chạy đúng theo yêu cầu hay không. Nó sẽ có hai loại unit test chính là Manual và Automated. Một số lợi ích khi bạn sử dụng unit test là:

    • Giúp cải thiện chất lượng đoạn mã trong chương trình.
    • Thời gian tìm lỗi được phát hiện nhanh hơn.
    • Cung cấp documentation cho trang web.
    • Đơn giản hóa quá trình gỡ lỗi.
    • Tiết kiệm chi phí khi xây dựng trang web.
    • Giúp bạn hiểu rõ hơn về hệ thống của mình thông qua những test case do bạn viết.

    Những Framework Unit Test Dành Cho Lập Trình Viên

    MochaJS là một framwork testing được sử dụng phổ biến trong lập trình web và hỗ trợ cho cả back-end(Nodejs) và front-end. Nó giúp bạn thực hiện kiếm tra không đồng bộ một cách đơn giản và dễ dàng. Ngoài ra nó còn có cộng động lập trình viên hỗ trợ đông đảo, nhiều hướng dẫn ví dụ chi tiết và được nhiều công ty cũng như website lớn tin tưởng sử dụng.

    Jest là một framwork testing tập trung vào sự đơn giản. Nó có thể làm việc với Babel, TypeScript, Node, React, Angular, Vue… Với các bài test được chạy song song trong các quy trình riêng nhằm tối đa hiệu suất cho chương trình. Ngoài ra nó còn có tài liệu hướng dẫn chi tiết, yêu cầu thiết lập không phức tạp và dễ dàng có thể mở rộng để phù hợp với yêu cầu của lập trình viên.

    AVA là một framework testing cho Javascript với API ngắn gọn và đưa ra những thông báo lỗi chi tiết trong quá trình kiểm tra. Một số điểm mạnh nó là cú pháp đơn giản, viết các test cho cú pháp Javascript mới nhất, hỗ trợ chức năng không đồng bộ, cung cấp chức năng promise…

    Jasmine là một framework testing dùng để kiểm tra các đoạn mã Javascript. Với cú pháp đơn giản giúp bạn viết test case một cách dễ dàng. Một số điểm mạnh là hỗ trợ cho cả front-end và back-end, có tài liệu mở rộng khi sử dụng với các framework khác, tốc độ thực thi nhanh, không sử dụng bất kỳ thư viện bổ sung nào…

    Karma mang lại một môi trường testing hiệu quả cho các nhà phát triển với các tính năng hữu ích như là có thể kiểm tra code trên nhiều thiết bị như trình duyệt, điện thoại, máy tính bảng…, mô tả các testing với Jasmine, Mocha, QUnit…, dễ dàng gỡ lỗi trực tiếp từ IDE thông qua WebStorm hay Google Chrome.

    Puppeteer là một thư viện NodeJS cung cấp các high-level API để sử dụng cho các ứng dụng dành riêng cho trình duyệt như kiểm tra thu thập dữ liệu, testing UI, kiểm tra các chrome extension, xem các vấn đề về hiệu suất, chụp ảnh màn hình và PDF của các trang…

    Nightwatch là một thư viện được xây dựng bằng NodeJS dễ dàng sử dụng cho các ứng dụng và trang web. Với cú pháp đơn giản, mạnh mẽ cho pháp bạn viết các test case một cách nhanh chóng thông qua Javascript và CSS. Quản lý tự động các dịch vụ Selenium hoặc WebDriver (ChromeDriver, GeckoDriver, Edge, Safari) trong một quy trình con riêng biệt. Sử dụng API WebDriver của W3C để điều khiển các trình duyệt thực hiện các lệnh và xác nhận trên các phần tử DOM.

    Cypss là một testing framework giúp bạn kiểm tra nhanh chóng dễ dàng với mọi thứ chạy trên trình duyệt. Một sổ điểm mạnh của nó là cách thiết lập đơn giản, tự động tải lại khi các test case thay đổi, các hình ảnh được chụp tự động khi chạy test case, có thể gỡ lỗi trực tiếp thông qua các cụ phổ biến như Chrome DevTools…

    Tape là một testing framework nhỏ gọn cung cấp bare-metal code giúp lập trình viên hoàn toàn tự do trong việc viết test case cho cả front-end và back-end. Ngoài ra nó cũng hỗ trợ cho ES6, coffee script tiêu chuẩn, Typescript và có thể chạy trên hầu hết các trình duyệt phổ biến hiện nay. Một hạn chế là nó không hỗ trợ global do vậy bạn cần thêm Tape vào mỗi tệp kiểm tra khi muốn thực hiện testing.

    Chai là một testing framework cho NodeJS và trình duyệt. Nó cung cấp 2 loại là TDD(Test-Driven Development) tập trung vào kiểm tra quy trình nội bộ, hiệu suất của code và BDD(Behaviour-Driven Development) ưu tiên giá trị được đưa ra trong yêu cầu. Ngoài ra nó cũng các bài viết hướng dẫn chi tiết cho người mới bắt đầu cũng như cộng đồng lập trình viên hỗ trợ đông đảo.

    Một số bài viết hướng dẫn sử dụng unit test

    JestAvaJasmineKarma

    Tổng kết:

    --- Bài cũ hơn ---

  • Tìm Hiểu Về Jestjs, Viết Unit Test Cho Javascript
  • Viết Unit Test Cho Javascript Với Jasmine
  • Tải Manualslib User Guides Owners Manuals Library Cho Máy Tính Pc Windows Phiên Bản
  • Guide Là Gì? Tất Cả Những Khái Niệm Về Guide Bạn Cần Biết
  • Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn
  • Unit Test Là Gì? Giới Thiệu Về Unit Test Và Ví Dụ

    --- Bài mới hơn ---

  • Unit Test Dùng Để Làm Gì Và Kinh Nghiệm Viết Unit Test Tốt Nhất
  • Hướng Dẫn Viết Unit Test Cho Laravel (P2)
  • Viết Unit Test Trong C# Với Nunit
  • Unit Test Cho Nodejs Với Mocha
  • Hướng Dẫn Viết Unit Test Cho Laravel (P3)
  • Lời nói đầu.

    Dành cho các bạn lười biếng =]]. Nêú các bạn không muốn đọc lý thuyết thì scroll xuống để xem ví dụ về cách viết unit test và hãy xem mình là ở vị trí nào?

    Bất cứ ai đã tham gia vào vòng đời phát triển phần mềm dù ít hay nhiều kinh nghiệm đều cũng đã từng nghe tới Unit Test. Unit Test là một cơ chế chấp nhận để khám phá phần mềm hoạt động tốt như thế nào theo các yêu cầu được chỉ định. Mặc dù mục đích của kiểm tra là tìm ra các lỗi, nhưng nó không thể đảm bảo sự vắng mặt của các lỗi khác, bất kể các trường hợp kiểm thử đã được thiết kế sáng tạo như thế nào.

    Có nhiều công ty không quan trọng vấn đề này nhưng nếu Công TY bạn bắt buộc nghiêm ngặt vấn đề này thì tôi tin và tôi viết vị trí của bạn đang ở đâu. Một lập trình viên lúc nào cũng cận thẩn trong việc code thì lúc nào cũng phải có test case.

    Tham gia cùng chúng tôi:

    Facebook: Cộng đồng lập trình javascript

    Facebook Cộng đồng giới thiệu bài viết, website, sản phẩm tăng traffic.

    Bài viết này sẽ cung cấp cho bạn những điều sau đây:

    • Unit Test là gì?
    • Unit Test có cần thiết không?
    • Unit Test có nhược điểm gì?
    • Viết Unit Test thông qua ví dụ.

    #Unit Test là gì?

    Bản thân bài kiểm tra đơn vị là một đoạn mã ngắn hoặc đoạn mã được thiết kế để xác minh hành vi của một đơn vị cụ thể để tạo ra kết quả vượt qua hoặc thất bại. Mục đích của thử nghiệm đơn vị là cho phép các nhà phát triển chạy càng nhiều thử nghiệm đơn vị càng tốt để xác định các lỗ hổng tiềm năng. Khi ứng dụng đã vượt qua thử nghiệm đơn vị, các hình thức thử nghiệm khác sau đó sẽ cần được áp dụng để xác nhận thêm.

    #Unit Test có cần thiết không?

    Câu trả lời đương nhiên là cần thiết với một Lập Trình Viên có trách nhiệm với những dòng code của chính bản thân mình.

    1 – Phát triển nhanh hơn.

    Một khi các devloper viết các test case thì việc gỡ bug sẽ ít dành thời gian hơn và sau đó sẽ tự tin hơn về việc thực hiện các thay đổi code. Những kỹ năng về mọi mặt sẽ phát triển nhanh hơn các Lập Trình Viên bình thường.

    Tính cận thận và trách nhiệm trong những bài unit test cũng khẳng định ở bên ngoài cuộc sống của họ.

    2 – Cấu trúc Code tốt hơn.

    Khi các nhà phát triển viết unit tests, sự nhấn mạnh của họ là suy nghĩ về cách mã của họ sẽ được sử dụng trên toàn hệ thống, điều này thường dẫn đến thiết kế tốt hơn.

    Và còn nhiều lợi ích khác như là giảm công việc cho các tester, giảm giá thành chi phí code, giúp giảm chi phí cho việc bảo trì trong tương lai…

    #Unit Test có nhược điểm gì?

    Mặc dù các lợi ích của Unit Test đang bắt đầu được hiểu rộng rãi hơn, nhưng vẫn còn một số lý do tại sao nó không được áp dụng đầy đủ hơn, điều này khiến tiềm năng của nó không được thực hiện.

    1 – Không có thời gian cho Unit Test.

    Viết Unit Test là tốn thời gian đó là lý do tại sao rất khó để đáp ứng thời hạn. Trong thực tế, Unit Test có thể tiết kiệm rất nhiều thời gian và nỗ lực phát triển trong thời gian dài.

    2 – Unit tests khác với viết code

    Đúng, bạn hãy nghĩ rằng để viết được một unit test đôi khi còn mất thời gian hơn viết một chức năng code. Và có thể có những Lập Trình Viên viết được code nhưng chưa chắc viết được test case. Không có gì đảm bảo, ngay cả khi mã được kiểm tra kỹ lưỡng, sẽ không có lỗi.

    #Viết Unit Test thông qua ví dụ

    Bây giờ mình sẽ làm một bài tập nho nhỏ cho các bạn hiểu về cách thức viết một unit test như thế nào?

    Mình sẽ lấy bài toàn Viết hoa chữ cái đầu tiên của mỗi từ trong Câu trong bài Sự Khác Biệt Về Kinh Nghiệm Trong Lập Trình Javascript để làm ví dụ:

    Sử dụng reduce() làm tăng hiệu quả và điều quan tâm là hiệu suất. Giải pháp dùng reduce() and map().

    const rest = word.slice(1);

    const firstLtr = word.charAt(0);

    return firstLtr.toUpperCase() + rest.toLowerCase();

    }

    if(!phrase) return phrase;

    Làm bài kiểm tra này, bạn sẽ vượt qua tất cả các bài kiểm tra:

    console.log(testResult);

    output:

    //Array(6)

    0: “passed”

    1: “passed”

    2: “passed”

    3: “passed”

    4: “passed”

    5: “passed”

    #Kết Luận

    Tham gia cùng chúng tôi:

    Facebook: Cộng đồng lập trình javascript

    Facebook Cộng đồng giới thiệu bài viết, website, sản phẩm tăng traffic.

    Tham khảo tại:

    https://www.guru99.com/unit-testing-guide.html https://areknawo.com/lets-talk-js-unit-testing/ https://blog.testlodge.com/what-is-unit-testing/

    --- Bài cũ hơn ---

  • Làm Sao Để Mô Tả Phần Lợi Ích (Why) Trong User Story
  • Cách Viết User Stories: Trải Nghiệm Phương Pháp Agile
  • User Story Là Gì Và Tiêu Chí Chấp Nhận
  • Để Tạo Ra Những User Story Tốt Nhất
  • User Story Là Gì? Ví Dụ? Cách Viết Tốt Nhất?
  • Viết Unit Test Cho Javascript Với Jasmine

    --- Bài mới hơn ---

  • Tìm Hiểu Về Jestjs, Viết Unit Test Cho Javascript
  • Unit Test Là Gì? 10 Frameworks Unit Test Cho Javascript
  • Hướng Dẫn Viết Unit Test Trong Angular
  • Hướng Dẫn Viết Unit Test Trong React
  • Unit Test Trong C# Với Nunit Và Moq
  • Blog có khá nhiều bài về code rồi nên hôm nay mình sẽ viết một bài để đổi gió.

    1. Nhắc lại sơ về Unit Test

    Trước khi có unit test, các lập trình viên thường code theo kiểu: code – test – fix lại – code tiếp – test lại – fix tiếp. Đôi khi chỉ vì sửa 1 lỗi nho nhỏ mà ta phải test lại rất nhiều lần. Để giải quyết vấn đề này, unit test và automation test ra đời. Mình không phải QA chuyên nghiệp nên không dám múa rìu qua mắt thợ, chỉ nói sơ về định nghĩa của 2 loại test này:

    • Unit test: Đây là test do developer viết, được chạy để kiểm tra các hàm do developer viết ra có sai hay ko. Unit test thường được chạy mỗi khi build để đảm bảo các hàm đều chạy đúng sau khi ta sửa code.
    • Automation test: Đây là test do QA viết, được chạy để kiểm thử hệ thống (Nếu không có automation test thì QA kiểm thử bằng tay, gọi làm manual test).

    Bài viết này chỉ tập trung vào unit test. Đây là test mà developer chúng ta phải viết. Các thư viện thường dùng để viết unit test là jUnit (Java), nUnit (C#), thư viện test của Microsoft, … Một số khái niệm cần biết trong unit test:

    • Setup: Đây là hàm được chạy trước khi chạy các test case, thường dùng để khai báo dữ liệu, cài đặt các biến.
    • Teardown: Đây là hàm được chạy sau khi các test case chạy xong, thường dùng để xóa dữ liệu, giải phóng bộ nhớ.
    • Assert: Mỗi test case sẽ có 1 hoặc nhiều câu lệnh Assert, để kiểm tra tính đúng đắn của hàm. Vd: Assert.Equals(4, Add(2,2));
    • Mock: Giả sử chương trình của bạn được chia làm 2 module: A và B. Module A đã code xong, B thì chưa. Để test module A, ta dùng mock để làm giả module B, không cần phải đợi tới khi module B code xong mới test được.

    2. Giới thiệu về Jasmine

    3. Demo Jasmine

    Để đơn giản, chúng ta sẽ tạo 1 file spec mới làm ví dụ, đặt tên là chúng tôi Ta sửa lại file html như sau:

    function Calculator() { chúng tôi = function(a, b) { return a+b;}; this.minus = function(a, b) { return a-b;}; this.multiply = function(a, b) { return a*b;}; Toiyeucogaihalan.com = function(a,b) {return a/b;} ; }

    Một số unit test cộng trừ nhân chia

    • Hàm describe dùng để gom nhóm, ghi chú cho nhiều unit test.
    • Hàm it tương đương với 1 unit test.
    • Hàm expect chính là hàm assert để kiểm tra tính đúng đắn của unit test

    describe("Cộng trừ", function() { var cal = new Calculator(); it("Một với một là hai", function() { expect(2).toBe(cal.add(1,1)); }); it("Hai với hai là bốn", function() { expect(4).toBe(cal.add(2,2)); }); it("Năm trừ hai bằng ba", function() { expect(3).toBe(cal.minus(5,2)); }); }); describe("Nhân chia", function() { var cal = new Calculator(); it("Năm nhân hai bằng mười", function() { expect(10).toBe(cal.multiply(5,2)); }); it("Sáu chia hai bằng ba", function() { expect(3).toBe(cal.pide(6,2)); }); });

    Chạy lại file SpecRunner.html, ta được kết quả. Giả sử ta cố ý sửa lại cho hàm minus chạy sai, ta sẽ thấy unit test báo hàm sai như sau: Bài viết tới đây là kết thúc. Ở phần 2, mình sẽ hướng dẫn chi tiết hơn về cách dùng hàm setup, teardown và mock với Jasmine. Các bạn có thể tải code sample của bài viết này ở đây: https://github.com/conanak99/jasmine-sample.

    --- Bài cũ hơn ---

  • Tải Manualslib User Guides Owners Manuals Library Cho Máy Tính Pc Windows Phiên Bản
  • Guide Là Gì? Tất Cả Những Khái Niệm Về Guide Bạn Cần Biết
  • Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn
  • Use Case Và Use Case Testing
  • Use Case Diagram Và 5 Sai Lầm Thường Gặp
  • Hướng Dẫn Viết Unit Test Trong Angular

    --- Bài mới hơn ---

  • Hướng Dẫn Viết Unit Test Trong React
  • Unit Test Trong C# Với Nunit Và Moq
  • Unit Testing Ứng Dụng C# Dùng .net Core Và Visual Studio Code
  • 【Hướng Dẫn】 Cách Viết Thư Upu Lần Thứ 50
  • Làm Sao Giỏi Văn, Giỏi Viết Lẫn Lách
  • Lợi ích của Unit test

    • Cải thiện design: Bắt tay vào code mà không để ý quá nhiều đến design là một lỗi phổ biến của các developer, việc viết unit test sẽ bắt buộc bạn phải suy nghĩ, thậm chí nghĩ đi nghĩ lại về design
    • Dễ dàng refactor: bởi vì bạn đã có các case test đảm bảo code của bạn chạy đúng như mong đợi, bạn có thể dễ dàng refactor code mà không lo sẽ tạo ra những bug mới
    • Test là một tài liệu về spec: nếu viết test chuẩn và đủ case, thì chỉ cần đọc test, ta cũng có thể hiểu rõ spec còn nhanh hơn cả đọc code
    • Việc viết test giúp developer tự tin hơn

    Bạn có thể cho rằng việc viết test quá tốn thời gian, nhất là viết test FE, có khi nó còn lâu hơn cả viết code nữa, nhưng mình nghĩ nó sẽ giúp tiết kiệm thời gian hơn khi bạn muốn refactor code hay phát triển tính năng mới, giảm thiểu được cả thời gian để fix bug so với việc không viết test.

    Giờ chúng ta sẽ bắt tay vào một ví dụ nhỏ nhưng khá đầy đủ sử dụng Angular, Jasmine và Karma. Phần tiếp theo của bài viết sẽ đề cập đến những điều sau:

    • Giải thích một chút về Karma và Jasmine
    • Karma config
    • Tạo một file test đơn giản
    • Test angular form
    • Test component với service

    Tạo project Angular với Jasmine và Karma

    Install angular-cli và tạo project mới

    Giải thích 1 chút về Jasmine và Karma không lại bảo nãy giờ cứ nói hoài mà không biết là gì

    • Jasmine: là một framework dùng để viết test, nó có các function có sẵn hỗ trợ viết các loại test khác nhau
    • Karma: là một Javascript tool được sử dụng để load ứng dụng và thực thi test của bạn. Karma sẽ được thực thi bằng dòng lệnh và sẽ hiển thị kết quả cho bạn biết mỗi khi bạn chạy trình duyệt.

    Để chạy thử chỉ cần gõ ng test. Lệnh này sẽ thực thi các case test, mở trình duyệt, hiển thị kết quả trên trình duyệt và trong console.

    Karma config

    Giờ hãy nhìn vào file Karma config được sinh ra từ angular-cli

  • frameworks: đây là nơi jasmine được set là framework để testing, nếu bạn muốn dùng 1 framework khác thì có thể điền vào đây.
  • autoWatch: nếu nó được set là true, test sẽ chạy chế độ watch mode, có nghĩa là mỗi khi bạn thay đổi bất cứ dòng code nào trong file test và lưu lại, nó sẽ tự động build lại và chạy lại.
  • browsers: đây là nơi để set trình duyệt và test sẽ chạy, mặc định sẽ là Chrome, nhưng bạn có thể sử dụng trình duyệt khác bằng cách khai báo ở đây.
  • Bắt đầu với một file test đơn giản

    Lướt qua 1 chút thì ở đây chúng ta đã

    • import các thư viện angular testing mà chúng ta sẽ sử dụng
    • Import các component phụ thuộc
    • Sử dụng describe để bắt đầu phần viết test với title trùng với tên component test.
    • Sử dụng async trước mỗi case test, mục đích là để các phần code không đồng bộ có thể kết thúc trước khi tiếp tục, nó tương tự với cách dùng async lúc viết code ý.

    Trước khi chạy bất cứ case test nào trong Angular, bạn cần phải config Angular testbed. Nó giúp tạo 1 môi trường cho component đang được test. Bất cứ module, component, service nào mà component bạn đang test cần, thì đều phải được đưa vào trong testbed. Cuối cùng, sau khi config xong, bạn sẽ gọi đến hàm compileComponents().

    Tiếp theo, chúng ta có 2 case test. Mình sẽ giải thích từng case một:

    Case đầu tiên, chúng ta sẽ kiểm tra xem component có thực sự chứa text chúng ta kì vọng trong phần title hay không. Đầu tiên, chúng ta cần 1 instance của app.component, vì vậy chúng ta sử dụng hàm createComponent(), tạo 1 đối tượng fixture, cho phép chúng ta tạo 1 instance của component. Sau khi đã có instance của app.component, chúng ta có thể kiểm tra giá trị của thuộc tính title có giống với text chúng ta kì vọng hay không bằng hàm toEqual().

    Test angular form

    Bắt đầu với 1 file HTML chúng tôi có chứa form

    Form này khá đơn giản nên không cần giải thích gì nhiều. Nút submit sẽ bị disabled nếu form invalid.

    Tiếp theo đến contact.component.ts

    Giờ đến file test

    Trông phức tạp hơn nhiều so với file test trên nhỉ, đừng lo, mình sẽ giải thích cụ thể từng phần đây

    Đầu tiên vẫn là phần import, không có gì khác lắm, ngoại trừ import thêm By để chọn element từ DOM.

    Trong beforeEach(), ta dùng promise cho hàm compileComponent(), khi promise được resolved, chúng ta sẽ tạo instance của component trong này luôn, để đỡ phải viết lại trong mỗi case test.

    Case đầu tiên chỉ đơn giản là kiểm tra giá trị thuộc tính text của component.

    Case thứ 2 kiểm tra giá trị của biến submittedlà true khi hàm onSubmit() được gọi đến.

    Case thứ 4 kiểm tra khi truyền vào những giá trị invalid, thuộc tính valid của form sẽ là false.

    Cuối cùng, case thứ 5 ngược lại với case thứ 4, khi truyền vào những giá trị valid, thuộc tính valid của form sẽ là true.

    Trước khi kết thúc bài viết, chúng ta sẽ đến với phần cuối cùng, là làm sao xử lý service khi component cần test sử dụng chúng.

    Test component với service

    Ví dụ một component sử dụng service

    Component này sẽ gọi sang service để lấy danh sách users, lúc viết test thì việc lấy users từ đâu cũng ko quan trọng, nên ta có thể tạo component mocking cho service này.

    Về cơ bản thì cũng giống mấy ví dụ trên, chỉ khác ở chỗ khi UserService được gọi đến, nó sẽ thay bằng UserServiceMock. UserServiceMock là một dummy service để trả về dummy data để chạy test. Vậy thôi, đó là cách bạn nên dùng để mock service cho component.

    Nguồn: https://medium.com/swlh/angular-unit-testing-jasmine-karma-step-by-step-e3376d110ab4

    --- Bài cũ hơn ---

  • Unit Test Là Gì? 10 Frameworks Unit Test Cho Javascript
  • Tìm Hiểu Về Jestjs, Viết Unit Test Cho Javascript
  • Viết Unit Test Cho Javascript Với Jasmine
  • Tải Manualslib User Guides Owners Manuals Library Cho Máy Tính Pc Windows Phiên Bản
  • Guide Là Gì? Tất Cả Những Khái Niệm Về Guide Bạn Cần Biết
  • Unit Test Với Junit 4X

    --- Bài mới hơn ---

  • Nhập Môn Unit Testing Trong .net
  • 8 Cách Trình Bày Văn Bản Trong Word Giúp Văn Bản Đẹp Hơn
  • Et Cetera (Etc.), And So On, And So Forth… In Ielts Writing
  • Bí Kíp Viết Đoạn Văn Bằng Tiếng Anh
  • Pie Chart Ielts: (Chi Tiết) Cách Viết Và Phân Tích Biểu Đồ & Từ Vựng Hay
  • Trong bài viết này chúng ta cùng tìm hiểu về test và unit test bằng JUnit 4.x.

    1.1 Code under test

    Những đoạn code được kiểm thử thường gọi code under test. Nếu bạn đang kiểm thử một ứng dụng nào đó thì nó được gọi là application under test.

    1.2 Test fixture

    Đây là các điều kiện để có thể bắt đầu kiểm thử. Ví dụ như là một đoạn String cố định được sử dụng để làm input cho một method nào đó. Chúng ta chỉ có thể kiểm thử nếu đoạn test đó có đầy đủ các thông số truyền vào.

    1.3 Unit test và unit testing

    Một unit test là một đoạn code nhỏ được viết bởi developer nhằm mục đích kiểm tra một hàm hay chức năng riêng biệt nào đó có kết quả đúng như kì vọng hay không. Tỉ lệ các đoạn code được kiểm tra bằng unit test được gọi là test coverage. Phạm vi kiểm tra của một unit test thường là một method hoặc một class. Những method hay class có phụ thuộc lẫn nhau nên được tách biệt ra khi viết unit test. Vì vậy, unit test không phù hợp để kiểm thử những interface phức tạp hoặc một component. Chúng ta nên sử dụng integration test cho những phạm vi lớn và phức tạp này.

    1.4 Integration test

    Một kiểm thử tích hợp (integration test) có nhiệm vụ kiểm tra hoạt động của một component hoặc một tập hợp các component. Loại kiểm thử này còn được biết đến với cái tên funtional test.

    Integration test sẽ kiểm tra toàn bộ hệ thống có làm việc như mong muốn không, do đó chúng giúp làm giảm các công việc kiểm thử thủ công.

    1.5 Performance test

    Kiểm thử hiệu năng được sử dụng để đánh giá các thành phần trong phần mềm được dùng đi dùng lại nhiều lần. Mục đích là để kiểm tra khả năng chịu tải cao, tốc độ tải trong điều kiện nhiều request.

    1.6 Behavior và state testing

    Một đoạn test được gọi là behavior test nếu nó kiểm tra các phương thức với các parameter truyền vào là chính xác và không quan tâm đến kết quả trả về là gì. Một đoạn test được gọi là state testing nếu nó validate kết quả trả về.

    1.7 Testing framework

    Trong java thì chúng ta có một vài framework hỗ trợ việc kiểm thử. Tiêu biểu nhất là JUnit và TestNG. Trong bài viết này chúng ta sẽ tìm hiểu về JUnit 4.x.

    1.8 Những đoạn test nên đặt ở đâu?

    Thông thường thì các đoạn unit test sẽ được tạo trong một folder hoặc một package riêng, tránh lẫn lộn với những đoạn code chính. Theo chuẩn build project của Maven và Gradle thì

    • src/main/java là nơi chứa Java class
    • src/test/java là nơi chứa test class.
    • Cung cấp Annotation để xác định việc xác thực phương thức.
    • Cung cấp Asertion cho kết quả mong muốn.
    • Cung cấp các Runner cho việc chạy thử.
    • Giúp viết code nhanh hơn mà chất lượng ngày càng tăng.
    • @Test – Đánh dấu một method là một method dùng để kiểm thử.
    • @Before@After : đánh dấu vị trí bắt đầu và kết thúc của một method test trong một class.
    • @BeforeClassAfterClass: Đánh dấu method chạy đầu tiên và cuối cùng trong một class test.
    • @Ignore hoặc @Ignore("Why disabled"): đánh dấu đoạn test nên được disabled. Nó được sử dụng khi các đoạn code chính đã được thay đổi nhưng các test case chưa được cập nhật hoặc điều chỉnh hoặc thời gian thực thi quá lâu nếu phải bao gồm cả nó. Tốt nhất là nên kèm theo giải thích tại sao lại disabled khi sử dụng annotation này.
    • @Test(timeout=100): Đoạn test sẽ được đánh là thất bại nếu thời gian thực thi lớn hơn 100 miliseconds.

    Ví dụ:

    public class SampleTest { @BeforeClass public static void setUpBeforeClass() throws Exception { //Method annotated with `@BeforeClass` will execute once before any of the test methods //in this class. //This method could be used to set up any test fixtures that are computationally expensive //and shared by several test methods. e.g. establishing database connections //Sometimes several tests need to share computationally expensive setup //(like logging into a database). While this can compromise the independence of tests, //sometimes it is a necessary optimization. //From http://junit.sourceforge.net/javadoc/org/junit/BeforeClass.html } @AfterClass public static void tearDownAfterClass() throws Exception { //Method annotated with `@AfterClass` will execute once after all of the test //methods are executed in this class. //If you allocate expensive external resources in a BeforeClass method you need //to release them after all the tests in the class have run. Annotating //a public static void method with @AfterClass causes that method to be //run after all the tests in the class have been run. All @AfterClass methods //are guaranteed to run even if a BeforeClass method throws an exception. //From http://junit.sourceforge.net/javadoc/org/junit/AfterClass.html } @Before public void setUp() throws Exception { //Method annotated with `@Before` will execute before each test method //in this class is executed. //If you find that several tests need similar objects created before they //can run this method could be used to do set up those objects (aka test-fixtures). } @After public void tearDown() throws Exception { //Method annotated with `@After` will execute after each test method //in this class is executed. //If you allocate external resources in a Before method you must //release them in this method. } @Test public void test1() { //A public void method annotated with @Test will be executed as a test case. } @Test public void test2() { //Another test cases } }

    Khi chạy đoạn code trên thì thứ tự thực thi sẽ là:

    1. Method được đánh dấu @BeforeClass.
    2. Method được đánh dấu @Before.
    3. Method kiểm thử đầu tiên được đánh dấu @Test (ở đây là test1()).
    4. Method được đánh dấu @After.
    5. Method được đánh dấu @Before.
    6. Method kiểm thử thứ hai được đánh dấu @Test ( ở đây là test2()).
    7. Method được đánh dấu @After.
    8. Method được đánh dấu @AfterClass.

    # 4. Assertions Khi muốn xác nhận một kết quả trả về có đúng như mong muốn không, chúng ta có danh sách Junit assertion cũ như sau:

    • org.junit.Assert.assertArrayEquals
    • org.junit.Assert.assertEquals
    • org.junit.Assert.assertFalse
    • org.junit.Assert.assertNotNull
    • org.junit.Assert.assertNotSame
    • org.junit.Assert.assertNull
    • org.junit.Assert.assertSame
    • org.junit.Assert.assertTrue

    Từ phiên bản JUnit4, chúng ta có thêm một method org.junit.Assert.assertThat cho phép sử dụng các matcher để xác nhận tốt hơn:

    • Dễ đọc hơn
      • assertThat(actual, is(equalTo(expected))); dễ đọc hơn assertEquals(expected, actual);
      • assertThat(actual, is(not(equalTo(expected)))); tốt hơnassertFalse(expected.equals(actual));
    • Thông báo lỗi tốt hơn

    • Linh hoạt hơn

        Có thể sử dụng nhiều điều kiện để assert bằng cách dùng các matcher như anyOf hay allOf.

    Nếu phương thức bạn cần kiểm thử có throw các exceptions thì chúng ta cũng có vài cách để kiểm tra xem nó có throw đúng như trong điều kiện mong muốn không. Ví dụ như chúng ta tạo một phương thức để đọc file và nó sẽ trả về một exception với message “The file ${file_name} does not exit!” trong trường hợp không tìm thấy file đó.

    @Test(expected = FileNotFoundException.class) public void testReadFile() throws IOException { FileReader reader = new FileReader("test.txt"); reader.read(); reader.close(); }

    @Test public void testReadFile2() { try { FileReader reader = new FileReader("test.txt"); reader.read(); reader.close(); fail("Expected an IOException to be thrown"); } catch (IOException e) { assertThat(e.getMessage(), is("test.txt (No such file or directory)")); } }

    @Rule public ExpectedException thrown = ExpectedException.none(); @Test public void testReadFile3() throws IOException { thrown.expect(IOException.class); thrown.expectMessage(startsWith("test.txt (No such file or directory)")); FileReader reader = new FileReader("test.txt"); reader.read(); reader.close(); }

    Thông thường chúng ta cần kiểm tra một method đơn với nhiều loại data test khác nhau hoặc nhiều input khác nhau. Trong trường hợp này chúng ta có Parameterized để thực hiện kiểm thử một cách dễ dàng và dễ đọc.

    https://javacodehouse.com/blog/junit-tutorial/ http://www.vogella.com/tutorials/JUnit/article.html

    --- Bài cũ hơn ---

  • Dịch Thuật Sách Hướng Dẫn Sử Dụng (User Manual / User Guide) Chuẩn
  • Business Analyst Cần Học Gì: Chuyên Nghiệp Khi Viết Hướng Dẫn Sử Dụng
  • Unit Test Là Gì? Khái Niệm Và Vai Trò
  • User Story Là Gì? User Story Mẫu Và Nguyên Tắc Ứng Dụng Trong Agile
  • 20+ Mẫu Thư Cảm Ơn Nhà Tài Trợ, Khách Hàng, Quý Đối Tác Chi Tiết Nhất
  • Hướng Dẫn Viết Unit Test Cho Laravel (P2)

    --- Bài mới hơn ---

  • Viết Unit Test Trong C# Với Nunit
  • Unit Test Cho Nodejs Với Mocha
  • Hướng Dẫn Viết Unit Test Cho Laravel (P3)
  • Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?
  • Hướng Dẫn Đặc Tả Use Case Quản Lý Khách Sạn 2022
  • Chào mừng các bạn tới với phần 2 của serie hướng dẫn viết Unit Test trong Laravel. Sau phần 1 nói về những lợi ích mà Unit Test có thể mang lại cho ứng dụng của chúng ta, phần này mình sẽ hướng dẫn các bạn sử dụng PHPUnit và chạy những dòng Unit Test đầu tiên

    Để có thể bắt đầu chạy test cho Laravel, trước tiên chúng ta cần một project Laravel nhỉ.

      Bước 1: Tạo một ứng dụng Laravel mới:

    composer create-project –pfer-dist laravel/laravel laravel-test-example

    Với “laravel-test-example” là tên thư mục chứa project Laravel.

    Chú ý: Nếu sử dụng MacOS/Linux, bạn phải set lại permission cho thử mục storagebootstrap/cache

      Bước 2: Bắt tay vào sử dụng PHPUNit

    Thật may mắn cho chúng ta, PHPUnit sẽ được Laravel cài đặt sẵn khi khởi tạo ứng dụng mới.

    Laravel sẽ khởi tạo sẵn chúng ta hai thư mục Là FeatureUnit. 2 thư mục này cũng sẽ tương ứng phương thức bạn test ứng dụng. Một số ví dụ về cách bạn sẽ test.

    • Feature Test: Bạn sẽ POST một dự liệu lên một REST endpoint, và kiểm tra xem API có trả về kết quả như mong muốn.
    • Unit Test: Khởi tạo một Model, và kiểm tra Model đó có đầy đủ các tham số như mong muốn hay không.

    Ngoài thư mục ./tests/ thì bạn cần quan tâm tới file chúng tôi Nơi đây sẽ chứa toàn bộ các tham số để chạy PHPUnit.

    Do trong serie này, mình sẽ hưỡng dẫn chủ yếu về Unit Test nên bạn không cần quá quan tâm tới thư mục Feature. Bên cạnh đó, bạn hoàn toàn có thể xoá bỏ Test Suite Feture đi.

    ./tests/Feature

    Sau khi save lại file, mở terminal lên và gõ command như sau

    vendorbinphpunit

    Để kiểm tra xem PHPUnit đã chạy được chưa. Và ta sẽ được kết quả như sau:

    Nếu như sau khi chạy ta được dòng chữ xanh nghĩa là tất cả các Test của chúng ta chạy thành công. Còn nếu có vấn đề gì khi chạy test, ta sẽ nhận được thông báo:

      Bước 3: Khởi tạo file Test

    Bạn sử dụng command này đẻ tạo file Test:

    php artisan make:test ExampleTest -unit

    Ta thấy trong câu lệnh có sử dụng –unit. Bằng việc thêm –unit là sẽ bảo Laravel hãy tạo vào thư mục Unit thay vì Feature.

    Quy ước khí khởi tạo file test:

    Các file test cần được ánh xạ 1-1 với codebase và tên file được thêm chữ Test.

    File trong thư mục app File trong thư mục test

    ./app/Foo.php

    ./tests/Unit/FooTest.php

    ./app/Bar.php

    ./tests/Unit/BarTest.php

    ./app/Controller/Baz.php

    ./tests/Unit/Controller/BazTest.php

    Chúng ta thử mở file chúng tôi có sẵn trong folder Unit

    Trước tiên ta nhận thấy khởi đầu file là namespace. Các Namespace khác nhau sẽ giúp ta tránh được tình trạng lặp tên.

    Nhìn vào function testBasicTest ta thấy function đó gọi tới một hàm assertTrue. Vậy assertTrue là gì ta ???

    assertTrue là một Assertion, Mình có tham khảo định nghĩa Asertion trên wiki như sau:

    Assertion là một câu lệnh khẳng định cho kết quả true – false, nó được đặt trong chương trình để chỉ cho lập trình viên thấy rằng xác nhận này luôn đúng ở vị trí đặt câu lệnh, hay nói một cách khác assertion kiểm tra một câu lệnh là đúng.

    Nói tó gọn như sau, ta sẽ truyền thao số vào các hàm Assertion và hàm sẽ trả ra true và false. Nếu true thì pass test , và ngược lại.

    PHPUnit có hơn 90 Assertion, nhưng đa phần mình sử dụng một phần rất nhỏ trong số đấy. Đây là một số assertion thuờng gặp:

    All Rights Reserved

    --- Bài cũ hơn ---

  • Unit Test Dùng Để Làm Gì Và Kinh Nghiệm Viết Unit Test Tốt Nhất
  • Unit Test Là Gì? Giới Thiệu Về Unit Test Và Ví Dụ
  • Làm Sao Để Mô Tả Phần Lợi Ích (Why) Trong User Story
  • Cách Viết User Stories: Trải Nghiệm Phương Pháp Agile
  • User Story Là Gì Và Tiêu Chí Chấp Nhận
  • Viết Unit Test Cho Spring Boot Application

    --- Bài mới hơn ---

  • Hướng Dẫn Chi Tiết Cách Viết Hồ Sơ Thi Jlpt Tháng 7/2021
  • #18: Viết Kịch Bản Từng Bước Một
  • #30: Viết Kịch Bản Phim Ngắn
  • Cách Ghi Các Kỹ Năng Một Cách Hiệu Quả Trên Sơ Yếu Lý Lịch Khi Đi Xin Việc
  • 5 Bí Mật Giúp Viết Kịch Bản Video Hiệu Quả
  • Đầu tiên, mình sẽ tạo mới một ứng dụng Spring Boot đơn giản để làm ví dụ:

    Class Hello:

    Class này định nghĩa một method cho phép chúng ta truyền tên và nó sẽ return lại chuỗi “Hello” cộng với tên mà các bạn truyền vào.

    Class Calculation:

    Class này cho phép chúng ta tính tổng của 2 số.

    Kết quả khi chạy chương trình này sẽ như sau:

    Ý tưởng là chúng ta cần viết Unit Test để kiểm tra khi ứng dụng chạy, 2 bean của các class Hello và Calculation phải được khởi tạo trong Spring container và các method của chúng phải return đúng giá trị mà chúng ta mong muốn.

    Để làm được điều này, trước tiên các bạn cần make sure là dependency của Spring Boot Test được khai báo trong trong tập tin chúng tôi của các bạn. Của mình khi tạo Spring Boot project sử dụng Spring Tool Suite, nó đã được include như sau:

    Có thể các bạn sẽ thắc mắc tại sao mặc định khi tạo Spring Boot project, phần Spring Boot Starter Test này lại exclude thư viện junit-vintage-engine đi. Nguyên nhân là bởi vì junit-vintage-engine là cho JUnit 4 và JUnit 3, chúng ta nên sử dụng latest version của JUnit là JUnit 5. Với khai báo dependency cho JUnit 5 như sau:

    Để viết Unit Test cho Spring Boot application, các bạn chỉ cần khai báo trong class Test một Annotation của Spring Boot Test @SpringBootTest là xong. Ví dụ:

    Hay:

    Class SpringBootUnitTestApplicationTests thì đã được thêm tự động rồi:

    Với annotation @SpringBootTest này, Spring Boot Test sẽ tự động chạy một Spring container và khởi tạo các bean trong Spring container này trong lúc chúng ta chạy test.

    Bean của các class nào sẽ được khởi tạo trong Spring container tuỳ thuộc vào cấu hình của chúng ta.

    Nếu các bạn khai báo thêm annotation @ContextConfiguration với value là các class chứa định nghĩa thông tin bean thì chỉ những bean được định nghĩa trong các class này mới được khởi tạo.

    Nếu các bạn không khai báo thêm annotation @ContextConfiguration thì Spring Boot Test sẽ tự động scan những class nào được khai báo với annotation @Configuration và được sử dụng với annotation @SpringBootConfiguration để khởi tạo bean.

    Trong ví dụ của mình thì mình đang sử dụng cơ chế auto component scan để khởi tạo bean trong Spring, không khai báo bean một cách tường minh nên những bean này là được sử dụng với annotation @SpringBootConfiguration để khởi tạo.

    Các bạn có thể thêm code test để kiểm tra các bean của các class Hello và Calculation phải được khởi tạo trong class SpringBootUnitTestApplicationTests như sau:

    Test cho các class Hello và Calculation sẽ như sau:

    Nếu các bạn chỉ muốn test class Hello, các bạn có thể tạo mới một class TestConfiguration với nội dung như sau:

    Rồi sau đó sử dụng annotation @ContextConfiguration để khai báo class TestConfiguration này vào để viết test:

    Trong trường hợp này, các bạn sẽ không thể lấy bean của class Calculation. Ví dụ:

    Sẽ gặp lỗi ngay:

    --- Bài cũ hơn ---

  • Pr Bản Thân Trong Cv Chuẩn Nhật Bản Chỉ Với 3 Bước
  • Cách Viết Bài Tự Pr Bản Thân 自己紹介 Kèm Ví Dụ Tiếng Nhat | Văn Phòng Luật Sư Hành Chính Hỗ Trợ Xin Visa Tsudanuma
  • Jd Là Gì ? Ý Nghĩa Và Vai Trò Bạn Cần Biết Về Jd Chuẩn Nhất
  • Mẫu Bản Mô Tả Công Việc (Job Description)
  • Cách Viết Writing Task 1 Table Cực Đơn Giản Trong Bài Thi Ielts
  • Hướng Dẫn Viết Unit Test Trong React

    --- Bài mới hơn ---

  • Unit Test Trong C# Với Nunit Và Moq
  • Unit Testing Ứng Dụng C# Dùng .net Core Và Visual Studio Code
  • 【Hướng Dẫn】 Cách Viết Thư Upu Lần Thứ 50
  • Làm Sao Giỏi Văn, Giỏi Viết Lẫn Lách
  • Hướng Dẫn Cách Viết Văn Hay Cho Các Bạn Học Sinh Mọi Lứa Tuổi
  • Toàn bộ project để bạn tham khảo

    Tại sao phải test?

    Rất hiển nhiên là chúng ta viết test nhằm mục đích hạn chế được càng nhiều lõi càng tốt, đảm bảo những gì chúng ta viết ra chạy đúng như chúng ta mong muốn. Một vài điểm trừ khi chúng ta phải viết test

    1. Là nó tốn thời gian và tương đối khó khăn (dù là lập trình viên kinh nghiệm cũng gặp không ít vất vả khi mới bắt đầu viết test)
    2. Test pass không có nghĩa ứng dụng, function của chúng ta chạy đúng 100%
    3. Cũng đôi khi, test fail, nhưng ứng dụng, function vẫn chạy hoàn toàn bình thường
    4. Trong vài trường hợp đặc biệt, chạy test trong CI có thể tốn tiền

    Test cái gì?

    Test các chức năng, function của ứng dụng, những cái mà user sẽ sử dụng. Nó giúp chúng ta tự tin vỗ ngực, ứng dụng đáp ứng đúng nhu cầu sử dụng

    Không test cái gì

    Thích quan điểm của Kent C về việc không nên đi quá chi tiết việc hiện thực. Việc mà code nó hiện thực như thế nào chúng ta không quan tâm, user không quan tâm, chúng ta chỉ quan tâm đầu vào-đầu ra của một function.

    Các thư viện của người khác viết cũng là thứ không cần thiết phải test, nó là trách nhiệm của người viết thư viện. Nếu không tin thì đừng dùng nó. Còn nếu thật sự có tâm bạn hãy hỗ trợ cho thư viện đó trên github bằng cách bổ sung test cho nó.

    Một vài triết lý cá nhân khi test

    Nhiều integration test, không dùng snapshot test, vài unit test, vài e-to-e test.

    Hãy viết thật nhiều integration test, unit test thì tốt nhưng nó không thật sự là cách mà người dùng sử dụng ứng dụng. Việc test chi tiết code hiện thực ra sao với unit test rất dễ.

    Integration test nên dùng mock (dữ liệu giả lập) ít nhất có thể

    Không nên test những cái tiểu tiết như tên hàm, tên biến, cách khai báo biến số, hằng số có hợp lý.

    Shallow vs mount

    Mount là phần html, css, js thật sự khi chạy, như cách mà browser sẽ thấy, nhưng theo cách giả lập. Nó không có render, paint bất cứ thứ gì lên UI, nhưng làm như thể nó là browser thật sự và chạy code ngầm bên dưới.

    Không bỏ thời gian ra để paint ra UI giúp test chạy nhanh hơn. Tuy nhiên nó vẫn chưa nhanh bằng shallow render

    Đó là lý do bạn phải unmountcleanup sau mỗi test, nếu không test này sẽ gây side-effect lên test kia.

    Mount/render thường được sử dụng cho integration test và shallow sử dụng cho unit test.

    Kiểu shallow render sẽ chỉ render ra một component đang test mà không bao gồm các component con, như vậy để tách biệt việc test trên từng component độc lập.

    Lấy ví dụ như component cha, con như sau

    Nếu chúng ta dùng shallow render component App, chúng ta sẽ nhận được DOM như sau, phần ChildComponent sẽ không bao gồm bộ “ruột” bên trong

    Với mount, thì chúng ta có

    react-testing-library là một thư viện khá ổn cho việc viết unit test react, tuy nhiên Enzyme là nền tảng cần nắm chắc, chúng ta sẽ đề cập nó trước

    Enzyme

    Cài đặt

    npm install enzyme enzyme-to-json enzyme-adapter-react-16

    Sơ qua những gì chúng ta sẽ import

    3 cái import đầu tiên là cho React và component đang test, sau đó đến phần của Enzyme, toJson là để chuyển shallow component của chúng ta ra thành JSON để lưu thành snapshot

    Cuối cùng là Adapter để làm việc được với react 16

    Thực hiện test chi tiết với Enzyme

    Trong component trên, chúng ta cố tình gõ sai chữ incremen, ứng dụng sẽ không chạy, nhưng khi chạy test thì vẫn pass

    File test

    Thứ nhất là cách viết test như vậy có vấn đề, chúng ko mô phỏng cách mà user sẽ sử dụng, chúng ta gọi thẳng increment().

    Vậy người nông dân biết phải làm sao?

    React-testing-library

    Từ thư viện react-testing-library, nó đưa ra một nguyên lý chung như sau

    Test càng gần với thực tế sử dụng của ứng dụng, test càng đem đến sự tự tin cho chúng ta

    Hãy tâm niệm nguyên lý này trong đầu, chúng ta sẽ còn bàn tiếp về nó

    useState

    Hay bắt đầu test React hook, chúng ta đã và đang sử dụng nó nhiều hơn là class component

    Prop sẽ được nhận từ component cha là App

    Với nguyên lý như đã nói, chúng ta sẽ thực hiện test như thế nào

    Thực hiện việc test

    Vì không sử dụng shallow render, nên chúng ta phải gọi afterEach(cleanup) để dọn dẹp sau mỗi lực thực hiện test

    getByText là phương thức nằm trong hàm render, còn vài kiểu query khác nữa, nhưng đây là kiểu mà chúng ta dùng nó nhiều nhất, có thể nói là đủ dùng.

    useReducer

    Reducer chúng ta sẽ test

    Action

    Cuối cùng là component sử dụng action và reducer đã định nghĩa

    Component này sẽ đổi giá trị của stateprop từ false sang true bằng việc dispatch một SUCCESS action

    Thực hiện test

    Trước tiên chúng ta test cái reducer bên trong khối describe, thực hiện một test đơn giản với giá trị initial state và sau khi có action success.

    Với ví dụ trên, reducer và action rất chi là đơn giản, bạn có thể nói không cần thực hiện unit test cho nó làm gì, nhưng trong thực tế sử dụng reducer sẽ không hề đơn giản thế, và việc test reducer là thực sự cần thiết, không những vậy, chúng ta còn phải test theo hướng chi tiết hiện thực bên trong.

    useContext

    Giờ chúng ta đi đến việc test một component con có thể cập nhập context state trong component cha.

    Thường thì context sẽ được khởi tạo trong một file riêng

    Chúng ta sẽ cần một component cha, nắm giữ Context provider. Giá trị truyền vào cho provider sẽ là giá trị state và hàm setState

    Component con, đây là component chúng ta muốn test

    Lưu ý: các giá trị của state, khởi tạo, cập nhập điều nằm trong App.js, chúng ta chỉ truyền giá trị này xuống các component con thông qua context, mọi thứ điều thực hiện ở App, cái này quan trọng cần nhớ để hiểu lúc test

    Với context chúng ta cũng không hề thay đổi cách làm như với useState, vẫn là tìm và đặt expect thông qua kết quả nhận được cuối cùng.

    Tại sao lại như vậy?

    How to Test React Components: the Complete Guide

    --- Bài cũ hơn ---

  • Hướng Dẫn Viết Unit Test Trong Angular
  • Unit Test Là Gì? 10 Frameworks Unit Test Cho Javascript
  • Tìm Hiểu Về Jestjs, Viết Unit Test Cho Javascript
  • Viết Unit Test Cho Javascript Với Jasmine
  • Tải Manualslib User Guides Owners Manuals Library Cho Máy Tính Pc Windows Phiên Bản
  • Web hay
  • Links hay
  • Push
  • Chủ đề top 10
  • Chủ đề top 20
  • Chủ đề top 30
  • Chủ đề top 40
  • Chủ đề top 50
  • Chủ đề top 60
  • Chủ đề top 70
  • Chủ đề top 80
  • Chủ đề top 90
  • Chủ đề top 100
  • Bài viết top 10
  • Bài viết top 20
  • Bài viết top 30
  • Bài viết top 40
  • Bài viết top 50
  • Bài viết top 60
  • Bài viết top 70
  • Bài viết top 80
  • Bài viết top 90
  • Bài viết top 100