Top 15 # Cách Viết Junit Test / 2023 Xem Nhiều Nhất, Mới Nhất 12/2022 # Top Trend | Toiyeucogaihalan.com

Unit Test Với Junit 4X / 2023

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 và @After : đánh dấu vị trí bắt đầu và kết thúc của một method test trong một class.

@BeforeClass và AfterClass: Đá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 {

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

Method được đánh dấu @BeforeClass.

Method được đánh dấu @Before.

Method kiểm thử đầu tiên được đánh dấu @Test (ở đây là test1()).

Method được đánh dấu @After.

Method được đánh dấu @Before.

Method kiểm thử thứ hai được đánh dấu @Test ( ở đây là test2()).

Method được đánh dấu @After.

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

Cách Viết Test Report (Part 1) / 2023

Hôm nay chúng ta sẽ tìm ra câu trả lời cho những câu hỏi: Làm thế nào để viết Test Report? Tại sao nên viết Test Report? Test Report được chuẩn bị cho ai? Bài viết này sẽ hữu ích cho những chuyên gia không chỉ trong lĩnh vực kiểm thử phần mềm mà còn từ những lĩnh vực khác như Project Managers, Product Owners, Developers …

Trong phần này mình sẽ làm rõ về những câu hỏi sau:

Test Report là gì, và tại sau chúng ta nên viết Test Report?

Test Report được chuẩn bị cho ai?

Ví dụ về thời gian làm Test Report (báo cáo kiểm thử)

1. Test Report là gì, và tại sau chúng ta nên viết Test Report?

Report (báo cáo) là mẫu tài liệu quan trọng và rút gọn về các thông tin thay đổi từ người thực thi tới khách hàng. Nhắc lại về quy trình kiểm thử phần mềm, chúng ta có những trạng thái sau:

Project creating (Khởi tạo dự án)

Test Plan preparing Execute testing (Chuẩn bị kế hoạch kiểm thử)

Test Case execution (Thực thi test case)

Finding bugs (Tìm lỗi)

Making reports (Làm báo cáo)

Như bạn có thể thấy các bản báo cáo được chuẩn bị có thể chứa các thông tin về hoạt động từ các trạng thái trước. Nên chúng ta có thể xác định Test Report như một tài liệu chứa các thông tin về các hành động đã được thực thi (Chạy test cases, phát hiện lỗi, thời gian bỏ ra…) và các kết quả của quá trình thực thi này (test case không thành công/thành công, số lượng bugs và crashes…)

Chúng ta có thật sự cần chuẩn bị Test Reports? Không nghi ngờ gì nữa câu trả lời là “Có”. Thực tế có ít nhất 3 lý do cho việc chuẩn bị Test Reports:

Bản Test Report tốt sẽ cho phép chúng ta (và không chỉ riêng chúng ta) có thể đánh giá trạng thái hiện tại của dự án cũng như chất lượng của sản phẩm.

Có khả năng đưa ra những quyết định sáng suốt nếu cần thiết.

Test Report có thể là tài liệu cuối cùng xác định việc sản phẩm đã sẵn sàng phát hành hay chưa.

Chất lượng và tính minh bạch là điều kiện bắt tiên quyết để tạo ra một Test Report. Bởi vì đấy là chìa khóa cho khách hàng đánh giá được giá trị công việc của chúng ta

2. Test Report được chuẩn bị cho ai?

Khi tạo một bản báo cáo, bạn phải hoàn toàn hiểu rõ bản báo cáo được viết cho ai, ai sẽ đọc nó. Dựa vào mức độ ưu tiên về người đọc mục tiêu, chúng ta cần phải xác định những thông tin nào bản báo cáo nên có. Có thể phân biệt được 3 nhóm mục tiêu sau:

Product Managers Họ tập trung vào việc thực thi theo các mốc deadline (ngày kết thúc), kết quả kiểm thử thuần túy mà không quan tâm đến các chi tiết kỹ thuật và thông số tổng thế.

Business Users (Product Owners) Như một điều luật, đây là những người đưa ra quyết định trong việc kết thúc kiểm thử. Họ cũng xác định chất lượng công việc đã hoàn thành. Điều quan trọng nhất với họ là kết quả cuối cùng, được chuyển thành dạng ngắn và rút gọn nhất (CÓ hay KHÔNG). Thông tin nên được trình bày dưới dạng trực quan (đồ thị, sơ đồ). Điều quan trọng là phải có ý kiến chuyên gia về khả năng phát hành sản phẩm mà không đi sâu vào chi tiết.

Tất nhiên, hầu như không thể viết một báo cáo mà sẽ phù hợp với tất cả các nhóm. Đó là lý do tại sao phải chắc chắn xác định đối tượng mục tiêu trước khi chuẩn bị một báo cáo kiểm thử. Tùy thuộc vào nó, nội dung sẽ rất khác nhau về cấu trúc và chứa các chi tiết khác nhau cần thiết cho nhóm cụ thể.

3. Ví dụ về thời gian báo cáo kiểm thử

Test Report ở khoảng thời gian giữa dự án nên thể hiển tiến độ công việc. Tiến độ không thay đổi nhưng linh động và được xác định bằng cách so sánh trạng thái của dự án ở các khoảng thời gian khác nhau (ngày, tuần, tháng). Trên thực tế, tiến độ là tập hợp các số liệu nhằm hiểu rõ các giai đoạn của dự án như thế nào.

Số liệu được tạo ra riêng biệt cho từng dự án, dựa trên các mục tiêu đã được xác định cho việc kiểm thử thành công. Chúng cho phép tạo ra sự so sánh tổng thế cho dự án một cách đủ nhanh.

Phiên bản của Test Report là một điều quan trọng khác và thường được dùng cho các báo cáo ở khoảng thời gian giữa dự án. Nó mô tả các nhiệm vụ được thực hiện bởi đội ngũ kiểm thử cho một phiên bản cụ thể của sản phẩm.

Bản báo cáo cuối cùng cho thấy một cái nhìn chung về công việc đã thực hiện (trong bối cảnh các thước đo chỉ số đã được thiết lập) và sự tiến triển của sản phẩm. Ngoài ra bạn cần phải cung cấp thông tin đầy đủ về trạng thái của sản phẩm tại thời điểm đó ( số lượng lỗi chưa sửa, liệu sản phẩm đã được kiểm thử đầy đủ chưa, hay là cần thêm chu kỳ kiểm thử nữa, độ sẵn sàng của sản phẩm cho việc phát hành)…

Trong bài viết sau về Test Report, mình sẽ nói chi tiết về nội dung của 1 Test Report, các gợi ý về các viết Test Report kèm theo ví dụ.

Tài Liệu Tham Khảo:

https://geteasyqa.com/qa/write-test-report/

Link phần 2: https://viblo.asia/p/cach-viet-test-report-part-2-end-LzD5dDYY5jY

All Rights Reserved

How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases) / 2023

Đầu tiên, chúng ta cùng tìm hiểu:

A. Testcase là gì?

Testcase là các trường hợp kiểm thử bao gồm các hành động được thực hiện nhằm kiểm tra từng chức năng của ứng dụng phần mềm có hoạt động đúng theo như mong muốn hay không.

B. Làm thế nào để có thể viết được Testcase tốt?

I. Trước khi bắt tay vào việc viết Testcase thì chúng ta cần nhớ những điểm sau đây:

Là 1 newbie, mới gia nhập công ty, chúng ta nên hỏi QA leader về template viết Testcase và xin file đó để làm. ( Vì mỗi công ty sẽ có cách viết khác nhau)

Viết Testcase nhớ phải bám sát tài liệu yêu cầu ( spec)

1 Testcase ID không quá 15 bước ( step)

Trước khi viết Testcase thì ta nên đọc và phân tích tài liệu thật kĩ càng, có chỗ nào chưa hiểu thì đặt Q&A ( Question & Answer) với các member trong team hoặc QA leader hoặc khách hàng để việc viết testcase và test được chính xác và chắc chắn hơn.

II. Những nguyên tắc để viết TestCase tốt:1. Các trường hợp kiểm thử cần phải đơn giản và minh bạch: (Test Cases need to be simple and transparent)

Tạo các testcase đơn giản nhất có thể nhưng vẫn phải rõ ràng và dễ hiểu.

2. Tạo Testcase với vai trò mình là End -user (người dùng ứng dụng đó)

Mục tiêu cuối cùng của bất kì dự án phần mềm nào cũng là đáp ứng được tất cả các yêu cầu của khách hàng. Vậy nên đặt vị trí của mình là người dùng thì sẽ thực hiện test được hiệu quả hơn. Chứ không nên có suy nghĩ mình chỉ là QA, chỉ là tester nên mình cứ test theo những gì spec nói thôi. Khi thấy UI nó khó dùng thì ta nên ta feedback lại với PM hay với mọi người để tất cả cùng cân nhắc có nên thay đổi hay không.

3. Mỗi testcase đều phải được xác định

Đặt tên ID cho từng testcase để dễ dàng theo dõi

b, Phân vùng tương đương (Equivalence Partition): Kỹ thuật này phân vùng phạm vi thành các phần / nhóm bằng nhau có xu hướng có cùng hành vi.

c,Kỹ thuật Bảng quyết định (Decision tables) : Phương pháp này tìm được những tác động khi kết hợp các yếu tốt đầu vào khác nhau và các trạng thái phần mềm mà phải thực hiện đúng các quy tắc nghiệp vụ khác.

d, Kỹ thuật đoán lỗi (Error Guessing Technique): Đây là đoán / dự đoán lỗi có thể phát sinh trong khi thực hiện test manual.

5. Review chéo (Peer Review): Sau khi tạo xong Testcase, hãy nhờ đồng nghiệp của bạn review giúp, có thể là QA leader hay QA cùng team để phát hiện ra các case mà bạn còn thiếu hoặc bạn chưa nghĩ tới.

C. Thực hành viết Testcase:

Khi join vào dự án, chúng ta được QA Leader giao cho nhiệm vụ là viết Testcase cho màn Login của 1 website với UI như thế này:

Ta sẽ viết theo format chuẩn như sau:

Testcase ID Test Scenario Test Steps Test Data Expected Results Actual Results Status

LG01

Check UI

As expected

Pass

LG02

Check button Sign in when user input valid data

4. User can login successfully and system go to the Homepage

As expected

Pass

LG03

Check button Sign in when user input invalid data

4. User cannot login and system shows error message: Email is invalid.

As expected

Pass

Qua 3 ví dụ trên các bạn có thể dễ dàng hơn với việc với Testcase rồi đúng không nào? Tương tự các case trên, các bạn áp dụng Kĩ thuật Bảng quyết định, ta sẽ có thêm các case sau:

Cách Tạo Api Với Rails (Phần 2) Viết Test Case / 2023

Tiếp theo Cách tạo API với Rails (phần 1) Mình sẽ hướng dẫn cách test căn bản cho API mình tạo. Thật ra mà nói thì mình phải viết test trước khi làm nhưng mà để tránh việc gây khó hiểu nên mình xin mạn phép đảo ngược qui trình.

Để thuận lợi hơn cho việc viết test case mình sử dụng gem rspec-rails

Test case thuộc tính của model mình đã tạo

Để dễ dàng hơn trong việc viết test case mình sử dụng thêm 2 gem:

Gem factory_girl_rails để tạo fixture data

Gem shoulda

Nhớ bundle install lại sau khi add gem

Chúng ta tạo lại model traveler

rails g model traveler first_name:string last_name:string birthday:datetime gender:string

Bây giờ cấu trúc app của chúng ta sẽ xuất hiện thêm phần này ( màu xanh lá cây)

Tạo fixture data

Vào file sau spec/factories/travelers.rb để kiểm tra lại fixture data mà FactoryGirls đã tạo. Mình sẽ edit lại một tí ( dựa vào gem ffake )

FactoryGirl.define do factory :traveler do first_name { FFaker::Name.first_name } last_name { FFaker::Name.last_name } birthday { FFaker::IdentificationESCO.expedition_date } gender { FFaker::Gender.maybe } end end

Test các thuộc tính của model

Bạn tạo model cho traveler và test cho traveler nên bạn sẽ viết test case tại file traveler_spec.rb

Vào file sau spec/models/traver_spec.rb để viết test case

require 'rails_helper' describe Traveler do before { @traveler = FactoryGirl.build(:traveler) } subject { @traveler } it { should respond_to(:first_name) } it { should respond_to(:last_name) } it { should respond_to(:gender) } it { should respond_to(:birthday) } end

Kiểm tra kết quả của test case Tại terminal bạn gõ theo cấu trúc rspec **đường đẫn file muốn test**

rspec spec/models/traveler_spec.rb

Test respond trả về khi request api

Test response code trả về thành công là 200

Test data trả về gồm những thành phần gì

require 'spec_helper' describe V1::TravelersController do before do @traveler = FactoryGirl.create :traveler get "/v1/travelers", format: :json end it 'return traveler information' do traveler = JSON.parse(response.body, symbolize_names: true).first expect(traveler[:first_name]).to eql @traveler.first_name expect(traveler[:last_name]).to eql @traveler.last_name expect(traveler[:gender]).to eql @traveler.gender expect(traveler[:birthday].to_s.to_i).to eql @traveler.birthday.to_s.to_i end it 'response code' do expect(response).to have_http_status(200) end end

Run lệnh này để kiểm tra kết quả

rspec spec/requests/v1/travelers_controller_spec.rb

Yah! đã xong