unit testing application layers

Question

I have a 3-tier application with Data access, service and presentation tiers. Where should i place the unit tests? On each layer? one presentation layer?

regards. Josh

Answer 1

Some of this depends on you're approach. If you've already got code in place, and you're putting unit tests in after the creation of the code - I'd start by adding some end to end acceptance tests. This will exercise all layers.

Then as you go in to make changes to any part of the system I'd start putting unit tests around the component being changed - first off just testing the existing functionality, then move onto adding unit tests for the new functionality. This works well if you're code is loosely coupled and split into well defined components. If not you're got a lot of work to do.

Depending on how thin your data access is, I would be less inclined to write any unit tests here as errors should be picked up quite cost effectively without having to unit test these.

If you're starting fresh, read up on BDD/TDD and use that approach to ensure quality.

Answer 2

Typically you will have all your unit tests in the middle tier.

You can certainly have integration tests in the DAL and manual or automated UI testing of that layer. If you find parts of those layers that can be unit tested then by all means do - although you should also question if they should be in those layers in that case.

Answer 3

Typically you would use unit tests - assuming you think JUnit, NUnit, etc. - for small isolated portions of your code, ideally single classes (doesn't always work that way, and that's why someone invented mocks).

Of the three layers you are mentioning you can find this type of test in all three of them. With proper design (e.g. MVC) you can test even large portions of the presentation layer. When testing the service layer or the domain layer (= business logic) it helps to mock the data access layer. When testing the data access layer try using an in-memory database for speed, or use an off-the-shelf ORM (Object-Relational Mapping) tool in the first place.

In general I'd recommend to use unit tests generously, wherever they provide value. Most development teams are not at risk to write too many unit tests. But also be aware that unit tests are just one aspect and that other types of tests and/or tools might be a better fit.

Answer 4

Where should i place the unit tests?

Frankly, everywhere.

If possible, every piece of code you write should have an automated test around it. If you're going the object oriented approach, every object should have a suite of unit tests. If your program is procedural, every function should have unit tests that exercise it.

Just make sure your unit tests run fast enough that other developers won't mind using them.

Answer 5

I was about to answer "each layer, you can't have too much test code", but that's not necessarily true.

I would have to say that it depends on how tightly coupled the layers are. If you can get full coverage using only the top layer, which is ideal anyway, you would not have to create separate tests for the lower layers.

If not, for instance if the data access layer is a generic library that's only partially used for the moment, you would at least add tests in that layer to get the coverage up and be a bit more confident that you don't have problems there that will show up later.