Unit Testing Folder Structure

[paul.r]

I am wondering how others structure their test code on disk - specifically what the folder structure looks like, and whether or not others include unit tests in a library with the source code (or do something else to keep the unit tests with the source code). Previously, I would put my classes in a library with the unit tests in the library as well - it made it easier to move or share the entire set of code between applications, but I am not sure that is the best way. On disc, it would look like this - 

Source Code

          Class A

                 Source - Folder with class and code

                 Unit Tests - Folder with unit tests 

                 Class A.Lvlib

Now, I am messing around with a structure that looks more like - (no libraries)

Source Code

             Class A (Folder with class and Code)

             Class B (Folder with class and Code)

Unit Tests

              Class A Unit Tests(Folder with unit tests)

              Class B Unit Tests (Folder with unit tests)

Ive just started this approach, so I am not sure which I prefer. Before I go too far down this path, I would like to get a little input from others on what they have used successfully. 

[James_McN]

Hi Paul,

For me it is always the latter.

Certainly I wouldn't put tests in the library - you want to keep test and execution code seperate.

I also like to be able to browse just test code easily in the project and so want it in it's own test folder - then I make the disk as your second case so it matches the project.

Cheers,

James

[paul.r]

Hi James,

Thanks for the feedback! Hm, so you even keep them in totally separate directories in the project? I am currently refactoring a couple of large applications, (and adding tests as I go) and I was thinking at least keeping the classes/tests together in the project would be helpful in seeing which classes have tests more quickly. Even long term, once I get most of the code tested (100+ classes in the projects so this will be a big undertaking, which is why I want to get input from others to ensure I make the best early decisions) I would think having test code directly next to the source would make things easier. 

Just out of curiosity, why do you want to be able to view just test code?

Thanks,

Paul

[James_McN]

Hi Paul,

Yeah I would keep them separate. It kind of comes from when I was using UTF and you could see previous results in the project window. There is less of a good reason with VI tester and I've not given it much thought since.

The main reason now is just seperation of test and source code which I just think gives a cleaner project structure and you can change the structures independently. I guess this is driven from my experiences in other languages where they keep it separate (JS normally has a seperate "spec" folder. C# actually has a seperate project) and I 've never questioned it much!

[FabiolaDelaCueva]

We keep our unit tests in a different folder. Normally the top level for our projects have:

Project file

Project alias and lvlps files

Documentation

Libraries

Unit tests

Keeping the Unit tests in a different folder makes it easier to programmatically run all the Unit tests in that folder.

Keep in mind that we do not let the projects get too big and we modularize and package as much as we can.

Let's say we are using DQMH. Each module is a library, most of the time one project would have one DQMH library and its classes as well as its unit tests. That code then gets packaged via VIPM or a PPL.

The package does not include the Unit tests, having the Unit tests in a different folder makes it easier to exclude.

Now we move to the next level, another project with a DQMH that calls the package above and has only its unit tests.

Another reason to have the Unit tests outside the library/class is that we believe we only have to test the public API of a library/class. 

Hope this helps,

Fab

[FabiolaDelaCueva]

I forgot we also have a VI Analyzer folder containing the cfg used for that project and the latest results (no timestamp in the name, source code control takes care of versioning).

[James_McN]

Let's say we are using DQMH.

---

I expect that for you that is quite accurate!

---

wrote:

Another reason to have the Unit tests outside the library/class is that we believe we only have to test the public API of a library/class. 

---

I was trying to think how to put this. The way I write the tests ends up being that each class has a closely related test suite but this isn't an entirely intentional relationship.

I like to create tests for given features that could encompass multiple classes so one suite could test multiple tasks. Or you may have unit tests that are more integration tests. These need their own home anyway.

---

[FabiolaDelaCueva]

Roy Osherove (author of the Art of Unit Testing) defines units as units of work. You are correct, this unit of work could be a single VI, a single class/library or a group of classes/libraries.