30/09/2018, 23:42
Về việc một programmer viết test case chứ không phải là unit test
Xin chào mọi người!
Mình hiện là 1 programmer đang làm cho công ty Nhật Bản. Đây cũng là công ty đầu tiên mình làm việc
Hiện tại công ty quy trình công ty mình chỉ có code, sau khi code thì viết testcase chứ không viết unit test và khi hỏi mọi người ở công ty bên Nhật họ cũng không biết là có quy trình viết unit test.
Có ai gặp trường hợp như mình không?
Mình hiện tại muốn cải tiến quy trình và thêm vào unit test mọi người có góp ý gì không?
Rất mong nhận được reply của các bạn
Bài liên quan
mình muốn biết công ty Nhật Bản của bạn được thành lập và hoạt động được bao lâu rồi.
người đứng đầu công ty của bạn biết gì về kỹ thuật không ?
Hề hề bạn làm ở chỗ nào thế? Mình làm ở tòa nhà Kangnam - Yokohama có khi lại làm cùng công ty mà không biết nhau… Bên mình thì:
…
Có một kết luận là nếu bạn muốn cải tiến quy trình hoặc học cái mới thì tốt nhất là không nên vào một trong hai công ty sau:
1.Công ty Nhật Bản
2.Công ty outsource
Trừ phi sếp bạn là người giỏi chứ không thì chẳng mấy ai chịu rủi ro để thay đổi cả.
hoạt động từ năm 92 rồi bạn
vậy thì như ý bạn @TamNinja nhé.
Nghe buồn nhỉ. Nếu chúng ta làm việc với môi trường như vậy, nếu có biến cố hay rủi ro gì thí dụ như mất việc làm thì như thế nào?
Bạn đã từng suy nghĩ đến chuyện này chưa?
Nếu có thì bạn đã có định hướng gì cho mình chưa
Mình đang làm cho công ty FOIS ^^
Mới đi làm mà, tập viết test case đi để cho chuyên nghiệp. Khi implement lên unit test thì cũng phải viết test case trước thôi.
Test case là công việc của tester hay programmer vậy bạn. Tại mình search thấy đa phần kiến thức này chỉ giành cho tester thôi
Công ty Nhật ít khi nào đuổi nhân viên.
Em mới làm nên mới thấy kỳ.
Nếu muốn luôn đổi mới thì hãy làm công ty mỹ hoặc châu âu.
Tuy theo công ty. Công ty Nhật thường dev làm luôn việc của tester.
Cám ơn anh
Anh đang làm công ty nào vậy?
mình cũng làm công ty nhật.
Suy nghĩ và viết các test case cho features/modules/application của mình làm ra là người biết quý trọng thời gian của bản thân và của người khác. Đồng thời khi viết test cases sẽ hệ thống được phần mình làm, sẽ làm nhanh và tiết kiệm thời gian.
Nếu các bạn chỉ mới junior hay intership thì thường chỉ làm mấy cái nho nhỏ, thì lúc này cảm thấy test cases ko có giá trị với mình. Chỉ đến khi bạn phải tự viết các module thì mới thấy, làm mà không tính trước sẽ nảy sinh rất nhiều vấn đề.
Mình đi làm lâu rồi cũng quen rồi.
Quan trọng của việc này là không sợ bị chửi, bỏ qua mấy anh hùng bàn phím và đón nhận nhiều đóng góp khi bạn sai hoặc nói gì đó chưa chính xác. Ở Việt Nam người ta ít có diễn đàn mở nào chứ nước ngoài thì nhiều lắm.
Ở Việt Nam thì đi đâu mà chả có việc. Bạn cứ làm được việc, tư duy trong sáng không đòi hỏi nhiều thì người ta nhận ngay ấy chứ.
Mình có nghe công ty này rồi. Bạn anh mình hình như cũng làm Br bên đó tên là Tự không biết bạn có biết anh ấy không.
Tất nhiên là làm việc mà được làm cái mình thích thì là hạnh phúc nhất. Mình cũng thích thế nhưng mà mình đang phải cày tiền tự trả tiền học đại học nên bắt buộc vẫn phải làm. Tuy nhiên có nhiều cách để bạn làm mình trở nên vui vẻ hơn trong công việc. Bạn cũng đừng lo lắng quá. Hồi trước mình cũng như bạn thôi. Sau rồi sẽ quen, bạn sẽ tìm ra những cách học mới phù hợp với bản thân hiện tại.
Chúc bạn vui.
Cảm ơn bạn rất nhiều
Cám ơn bạn nhiều nhé
Test case nếu có thời gian thì dev cũng nên viết rồi cho tester so sánh / review với bản của tester. Hiểu testcase tức là hiểu feature, chứ cứ nói xơi xơi là mình hiểu flow rồi thì đâu có ai kiểm chứng được. Nó cũng giống như việc truy bài vậy, phải check chéo với nhau thì mới biết thuộc bài hay không?
Tuy nhiên, test case của dev viết ra cũng không cần chi tiết như tester, chỉ cần tóm vài ý là được. Hoặc nếu ngon nữa thì mỗi test case mình làm một function trong unit-test rồi dùng jdoc export ra (nhớ là các function này phải có comment đầy đủ thì khi ra doc tester mới hiểu được)
Vẫn còn nhớ cái tescase này, làm cho nhật, nó qui định trung bình 10 dòng code phải có 1 test case, Viết xong con đó tính ra chụp hình 1400 test case. Cả team chụp 1 tuần, giờ đâm ra sợ cái testcase này, làm cho tụi Mỹ cùng làm testcase nhưng đỡ hơn, chủ yếu testcase cho functional.
Lại có thằng làm testcase xong yêu câu trung binh 1000 line code phải ra khoảng 10 bug. qua it bug hay quá nhiều bug cũng phải bao cáo nguyên do. chắc định thử sức chịu đựng anh em
Mình ít thấy testcase theo dòng mà thường là test-case theo chức năng. Ví dụ với màn hình login (viết BDD chẳng hạn) sẽ có các test case sau:
. Nhập đúng nhưng account bị inactive, báo lỗi acc đã bị khóa.
. Login bằng google+ nhưng không nhận được response từ google+
Khi đó sẽ có các test function sau:
mỗi function là 1 test case và mình ghi rõ đầu vào đầu ra ở hàm mô tả (hoặc cho 1 dataset in/out vào đó). Dùng jsdoc generate ra, cho vào excel, thế là xong. Các hàm này chưa cần implement gì cả nên assert sẽ toàn fail nếu chạy cả test suite. Khi nào sếp bảo là viết unittest đi thì mình implement (tuy nhiên, hay nhất là nên viết assert trước khi viết function cần test, như vậy sẽ nhanh hơn là viết function trước, sau viết test case. Với lại, chạy ra xanh đỏ nhìn cũng hay hay, gây hứng thú phết. Đỏ lòm là bực mình mà xanh rì là sướng)
Làm unittest hay ở chỗ mình không cần phải nhớ có bao nhiêu case cần trap trong óc làm gì cả. Tất cả rành rành ở IDE rồi, đỡ phải lôi tài liệu, đỡ phải nhức đầu, … Nói chung, cứ cái gì cần nhớ thì ghi luôn vào IDE là hay nhất.
À, với cả vụ viết test case phải làm trước khi làm code thì mình mới rõ cần bao nhiêu if else để trap qua các case chứ. Chứ code xong rồi, viết testcase thì thành ra là viết report xem chức năng này hoạt động thế nào thì đúng hơn.
Công ty mình là outsource đây.
Code viết ra phải có test.
Dùng Git quản lý
Chat bằng Slack
Mô hình Scrum
Còn có cả Continuous Integration.
…
Cám ơn bạn. Reply rất hữu ích <3