A question about unit tests

  • Thread starter Thread starter csharper
  • Start date Start date
C

csharper

I am not sure how many of you here to TDD.

I have 1 quick question about unit tests.

I am trying to have all of my methods unit-tested. But I am not sure if I should have a MyMethodTest for each and every of MyMethod ("MyMethod" is simply a place holder, it can be the name of any method).

For example, I have this unit test:

[Test]
public void GetEmployeeTest()
{
//1. Create a new Employee.
Employee obama = new Employee() {Name = "Barack Obama", ManagerId = 1};
int newEmployeeId = Employee.AddEmployee(obama);

//2. Retrieve it and verify
Employee obama2 = Employee.GetById(newEmployeeId);
Assert.IsNotNull(obama2);
Assert.IsTrue(obama2.Name == "Barack Obama");
Assert.IsTrue(obama2.ManagerId == 1);

//3. Delete this Employee to clean up.
Employee.Delete(newEmployeeId);

//4. Now retrieve it.
Employee obama3 = Employee.GetById(newEmployeeId);
Assert.IsNull(obama3);
}

As you see, in this GetEmployeeTest unit test, I have called 3 of my methods:

AddEmployee(Employee employee);
GetById(int employeeId);
Delete(int employeeId);

Do I still need to have AddEmployeeTest and a DeleteEmployeeTest?

Or is my GetEmployeeTest shown above a bad unit test? But I do like to insert some junk and then clean up the junk.

I understand that it is better to use a repository pattern and test withouta database, but I haven't gone that far yet.

As I wrote up to this point, I wikepeded it and found the following from
http://en.wikipedia.org/wiki/Unit_testing .

<quote>
Separation of interface from implementation

Because some classes may have references to other classes, testing a class can frequently spill over into testing another class. A common example of this is classes that depend on a database: in order to test the class, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own class boundary, and especially should not cross such process/network boundaries becausethis can introduce unacceptable performance problems to the unit test-suite. Crossing such unit boundaries turns unit tests into integration tests, and when test cases fail, makes it less clear which component is causing thefailure. See also Fakes, mocks and integration tests

Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mockobject. By abstracting this necessary attachment from the code (temporarily reducing the net effective coupling), the independent unit can be more thoroughly tested than may have been previously achieved. This results in a higher quality unit that is also more maintainable.
</quote>

I guess what this wikipedia entry says does constitute the best practice. You people never unit test writing to a database?
 
I am not sure how many of you here to TDD.
Click to expand...

Hopefully everyone working with software development
do use unit testing.
I have 1 quick question about unit tests.

I am trying to have all of my methods unit-tested. But I am not sure if I should have a MyMethodTest for each and every of MyMethod ("MyMethod" is simply a place holder, it can be the name of any method).

For example, I have this unit test:

[Test]
public void GetEmployeeTest()
{
//1. Create a new Employee.
Employee obama = new Employee() {Name = "Barack Obama", ManagerId = 1};
int newEmployeeId = Employee.AddEmployee(obama);

//2. Retrieve it and verify
Employee obama2 = Employee.GetById(newEmployeeId);
Assert.IsNotNull(obama2);
Assert.IsTrue(obama2.Name == "Barack Obama");
Assert.IsTrue(obama2.ManagerId == 1);

//3. Delete this Employee to clean up.
Employee.Delete(newEmployeeId);

//4. Now retrieve it.
Employee obama3 = Employee.GetById(newEmployeeId);
Assert.IsNull(obama3);
}

As you see, in this GetEmployeeTest unit test, I have called 3 of my methods:

AddEmployee(Employee employee);
GetById(int employeeId);
Delete(int employeeId);

Do I still need to have AddEmployeeTest and a DeleteEmployeeTest?

Or is my GetEmployeeTest shown above a bad unit test? But I do like to insert some junk and then clean up the junk.
Click to expand...

One unit test per method is a nice ideal, but it is not always
possible in practice. Many classes carry state.

Each unit test should test something very specific though.

In the case above I would be tempted to do a:

[Test]
public void EmployeeCRUD()
I understand that it is better to use a repository pattern and test without a database, but I haven't gone that far yet.

As I wrote up to this point, I wikepeded it and found the following from
http://en.wikipedia.org/wiki/Unit_testing .

<quote>
Separation of interface from implementation

Because some classes may have references to other classes, testing a class can frequently spill over into testing another class. A common example of this is classes that depend on a database: in order to test the class, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own class boundary, and especially should not cross such process/network boundaries because this can introduce unacceptable performance problems to the unit test-suite. Crossing such unit boundaries turns unit tests into integration tests, and when test cases fail, makes it less clear which component is causing the failure. See also Fakes, mocks and integration tests

Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mock object. By abstracting this necessary attachment from the code (temporarily reducing the net effective coupling), the independent unit can be more thoroughly tested than may have been previously achieved. This results in a higher quality unit that is also more maintainable.
</quote>

I guess what this wikipedia entry says does constitute the best practice. You people never unit test writing to a database?
Click to expand...

It is by definition important that unit tests actually test a unit not
half the system.

With a pragmatic view that becomes something like:

DAL unit test---DAL---database is fine
BLL unit test---BLL---DAL---database is questionable
BLL unit test---BLL---DAL mockup is fine

Arne
 
I am not sure how many of you here to TDD.

I have 1 quick question about unit tests.

I am trying to have all of my methods unit-tested. But I am not sure if I should have a MyMethodTest for each and every of MyMethod ("MyMethod" is simply a place holder, it can be the name of any method).

For example, I have this unit test:

[Test]
public void GetEmployeeTest()
{
//1. Create a new Employee.
Employee obama = new Employee() {Name = "Barack Obama", ManagerId = 1};
int newEmployeeId = Employee.AddEmployee(obama);

//2. Retrieve it and verify
Employee obama2 = Employee.GetById(newEmployeeId);
Assert.IsNotNull(obama2);
Assert.IsTrue(obama2.Name == "Barack Obama");
Assert.IsTrue(obama2.ManagerId == 1);

//3. Delete this Employee to clean up.
Employee.Delete(newEmployeeId);

//4. Now retrieve it.
Employee obama3 = Employee.GetById(newEmployeeId);
Assert.IsNull(obama3);
}

As you see, in this GetEmployeeTest unit test, I have called 3 of my methods:

AddEmployee(Employee employee);
GetById(int employeeId);
Delete(int employeeId);
Click to expand...
I won't question how the Employee type works and just assume pseudo
code ;)
Do I still need to have AddEmployeeTest and a DeleteEmployeeTest?
Click to expand...
The test above does not consider all possible code paths. For example
the Employee.GetById method should have at least two tests :

[Test]
public void EmployeeGetByIdWIthValidIdReturnsProperEmployee(){...}
[Test]
public void EmployeeGetByIdWIthInvalidIdReturnsNull(){...}

Both the add and delete functionality should have similar tests.

I believe such granularity is important because a proper suite of
tests provides much value. The tests represent a list of what the
software can & can't do and acts as sample code showing how to
interact with API; an excellent form of documentation. Of course tests
will provide immediate feedback on any changes.
Or is my GetEmployeeTest shown above a bad unit test? But I do like to insert some junk and then clean up the junk.

I understand that it is better to use a repository pattern and test without a database, but I haven't gone that far yet.

As I wrote up to this point, I wikepeded it and found the following from
http://en.wikipedia.org/wiki/Unit_testing .

<quote>
Separation of interface from implementation

Because some classes may have references to other classes, testing a class can frequently spill over into testing another class. A common example of this is classes that depend on a database: in order to test the class, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own class boundary, and especially should not cross such process/network boundaries because this can introduce unacceptable performance problems to the unit test-suite. Crossing such unit boundaries turns unit tests into integration tests, and when test cases fail, makes it less clear which component is causing the failure. See also Fakes, mocks and integration tests

Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mock object. By abstracting this necessary attachment from the code (temporarily reducing the net effective coupling), the independent unit can be more thoroughly tested than may have been previously achieved. This results in a higher quality unit that is also more maintainable.
</quote>

I guess what this wikipedia entry says does constitute the best practice. You people never unit test writing to a database?
Click to expand...

As the name Test Driven Design suggests the actual functional
implementation can be deferred. The first tests should come from high
level of abstraction. Testing the various pieces of code responsible
for CRUD functionality is initially done with mock objects. Later when
the actual implementation is in place, the same tests are used against
that implementation.

regards
A.G.
 
I am not sure how many of you here to TDD.

I have 1 quick question about unit tests.

I am trying to have all of my methods unit-tested. But I am not sure if I should have a MyMethodTest for each and every of MyMethod ("MyMethod" is simply a place holder, it can be the name of any method).

For example, I have this unit test:

[Test]
public void GetEmployeeTest()
{
//1. Create a new Employee.
Employee obama = new Employee() {Name = "Barack Obama", ManagerId = 1};
int newEmployeeId = Employee.AddEmployee(obama);

//2. Retrieve it and verify
Employee obama2 = Employee.GetById(newEmployeeId);
Assert.IsNotNull(obama2);
Assert.IsTrue(obama2.Name == "Barack Obama");
Assert.IsTrue(obama2.ManagerId == 1);

//3. Delete this Employee to clean up.
Employee.Delete(newEmployeeId);

//4. Now retrieve it.
Employee obama3 = Employee.GetById(newEmployeeId);
Assert.IsNull(obama3);
}

As you see, in this GetEmployeeTest unit test, I have called 3 of my methods:

AddEmployee(Employee employee);
GetById(int employeeId);
Delete(int employeeId);
Click to expand...
I won't question how the Employee type works and just assume pseudo
code ;)
Do I still need to have AddEmployeeTest and a DeleteEmployeeTest?
Click to expand...
The test above does not consider all possible code paths. For example
the Employee.GetById method should have at least two tests :

[Test]
public void EmployeeGetByIdWIthValidIdReturnsProperEmployee(){...}
[Test]
public void EmployeeGetByIdWIthInvalidIdReturnsNull(){...}

Both the add and delete functionality should have similar tests.

I believe such granularity is important because a proper suite of
tests provides much value. The tests represent a list of what the
software can& can't do and acts as sample code showing how to
interact with API; an excellent form of documentation. Of course tests
will provide immediate feedback on any changes.
Click to expand...

That is a very good point.

There should be sufficient unit tests to test both the success
case and all the different failure cases.

(I would probably not put the expected behavior in the method name
though)

Arne
 
Back
Top