kiến thức Testing & Checking

Unit Test thì có hẳn 1 bài này khá hay: https://martinfowler.com/bliki/UnitTest.html

Theo mình unit mình gọi là 1 code element, nó có thể là one class, method hay 1 group classes/methods mà mình . Việc làm unit test phải tự hỏi l value nó mang lại là gì, tại sao cần làm unit test

=> Lúc này lật cái bàn qua mô hình kim tự tháp cổ điển bên testing
View attachment 898260

Khi bắt đầu test 1 cái gì luôn quan niệm là test này tui có thể làm ở layer khác ko, ví dụ đang làm E2E tests mà có 1 vài cái test nếu thấy unit test được thì prefer unit test, ko prefer E2E tests nhiều vì đơn giản: E2E test lâu, hay bị flaky (lúc pass, lúc failed etc ). Bản thân thằng Google cũng có 1 bài dài nói về cái này : https://testing.googleblog.com/2020/11/fixing-test-hourglass.html

Unit Test hiệu quả là phải cân đo đong đếm dc, cái này dev gọi là code coverage, bên cty mình xài https://www.eclemma.org/jacoco/.
Và nó chỉ thực sự hiệu quả khi việc unit test nhanh và mang lại kết quả consistent . Unit Test test logic của cái code, test xem có những issues nào mà mình PHÁT HIỆN dc càng sớm càng tốt chứ ko phải chờ tới khi build -> QA vào test thì phát hiện ra issue trong khi chỉ cần xài unit test là detect dc rồi.
cảm ơn bạn chia sẻ, mình cũng đang làm test đây :D

Chia sẻ 1 chút là hiện tại thì đang chia theo auto _ manual nhưng thực tế mình nghĩ k nên chia như vậy, tester hãy là người đảm bảo về chất lượng của sản phẩm, có thể = nhiều cách (auto, manual, watever,..)

Và Tester nên có kiến thức về business knowledge kĩ nhất trong team (chắc chỉ sau mỗi BA)
 
Back
Top