Về việc một programmer viết test case chứ không phải là unit test

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ì:

• Không có unit test
• Không có tester
• Không dùng github
• Code Android bằng Vim
• Quản lí task bằng Redmine
• Chat bằng Hangout
  …

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é.

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ả.

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

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?

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.

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

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 đề.

Nghe buồn nhỉ.

Mình đi làm lâu rồi cũng quen rồi.

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 thích viết UnitTest bạn có thể tìm đến học viện Agile hoặc join vào nhóm của Hà Nội Scrum để được thực hành mỗi thứ bảy hai tuần kế tiếp.
• Nếu thích học cái mới bạn có thể lập team làm freelance.
• Nếu thích bồi đắp cái cũ bạn có thể đi dạy, share kiến thức hoặc làm các buổi seminar. Bạn có thể join vào Google Developer Group nếu có khả năng hoặc tự mình share kinh nghiệm bằng cách viết blog, dạy học trên Skype (Free hay có phí tùy vào trình độ của bạn và học viên)
  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.
• Nếu bạn thấy khách hàng làm không ổn thì bạn tự thay đổi. Nói chung sếp mình ảnh bắt mình test app bằng cách bấm đi bấm lại hai cái nút xem máy có nóng lên không thì mình viết cái app Python send key qua adb chẳng hạn. Quan trọng là bạn mong muốn thế nào thôi.

Nếu có thì bạn đã có định hướng gì cho mình chưa

Ở 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 đang làm cho công ty FOIS ^^

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:

• Vào màn hình login, check các input để trống và focus để vào input username / email.
• Nếu chưa nhập đủ 2 input thì nút login bị disable.
• Nhập đúng, vào màn hình home.
• Nhập sai format email, có thông báo lỗi.
• Nhập sai email / password, báo lỗi không match.
  . Nhập đúng nhưng account bị inactive, báo lỗi acc đã bị khóa.
• Login bằng google+ ok.
  . Login bằng google+ nhưng không nhận được response từ google+

Khi đó sẽ có các test function sau:

• testInputInit()
• testInputValidateNull()
• testLoginOK()
• testInputValidateEmail()
• testInputNotMatchEmailPassword
• testLoginInactive()
• testLoginGoogleOK()
• testLoginGoogleTimeout()

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