Làm sao để test hàm trả về là void?

[andynguyen (Anh Nguyen)]

Như cái tiêu đề mình viết. Mình muốn viết Unit test cho một cái C# app nhưng đa phần method kiểu trả về là void, và các trường dữ liệu thì đều là private. Cho mình hỏi làm sao để viết Unit test cho những method như vậy để kiểm tra xem nó chạy có đúng ko?

Ví dụ đơn giản như vầy thôi

public void setAge(int age)
{
       this.age = age;
}

Bây h không có getter thì làm sao mình biết code chạy đúng trong trường hợp không debug?

Mình có google thì thấy Mock test. Nhưng mock thì không thể test được method chạy có đúng không. Nó dùng để kiểm tra xem cái method đó có được gọi và được gọi bao nhiêu lần thôi. Cái mình cần là kiểm tra behavior.

[bossageek]

mình chưa làm qua C# và unit test trong C# nhưng ý tưởng có thể giống nhau biết đâu sẽ giúp được bạn
hàm setAge của bạn đang thực hiện side effect và ở đây mình viết mã giả nhé

User user = new User();
int age = 18;
user.setAge(age);
Boolean result = testWrapper(user.age).shouldEqual(age);

[library (La biblioteca)]

Hi there,

Thường thì cậu chỉ nên test unit cho method nào có chứa logic thôi
Như ví dụ của cậu, có vẻ như cậu đang thử test cho setter của 1 entity/value object. Về cơ bản, getter/setter để không chứa logic, nên cậu không cần phải confirm đâu
Coverage của getter/setter nên được cover ở business logic rồi

Trong TH cậu cần test các method chứa logic nhưng trả về void (thực ra là các thủ tục - method dạng này quan tâm tới thứ tự thực hiện của công việc, không quan tâm tới kết quả trả về), vì chứa business logic, method kiểu đó nên tung exception khi bất cứ bước nào bị thất bại.
Khi đó, cậu sẽ có:

• Happy scenario: method trả về void không tung bất cứ exception nào. Cậu có Unit test vô cùng dễ viết, chỉ cần gọi hàm đó thôi
• Sad scenario(s): method tung exception khi một bước nào đó bị thất bại. Cậu sẽ cần kỳ vọng exception được tung ra với 1 số điều kiện nhất định.
  Thường sad scenario sẽ là số nhiều, vì thủ tục thường có nhiều bước, và bất cứ bước nào cũng đều có thể thất bại vì 1 lý do nào đó.

Nhiệm vụ của Unit test của cậu là cover hết toàn bộ các sad scenario đó

Hope it helps!

P/s: Trong TH method của cậu thay đổi giá trị của 1 private property internally (điều này cũng thường chứng tỏ cậu có design smell ), cậu có thể dùng Reflection để lấy giá trị của private property đó để kiểm tra.
Nhưng như tớ có đề cập, cậu có bad design, nên có lẽ xem lại design trong TH này sẽ tốt hơn