The Root Level Test Directory
Here is an example of a github project that writes the unit tests in the way that I don't like:
Notice how there is a "test" folder in the root level of the project in the same directory as the "app" folder. When you do this you have to make a parallel directory structure. It can be hard to scroll and find the right test, to switch between tests and application code, and to determine where tests are missing. It is only aesthetically pleasing to someone looking at the finished project, but it is very much not fun for someone developing and writing code with this layout (at least less fun than the alternative).
Throw the Tests in the Soup
The approach I like to take is that you throw the unit tests right in the app and src directories with all the other application code. Why I do this? There are basically three reasons:
From a developer perspective, it's way nicer having tests right in with the source code, but is this method actually all-around better?
The main argument against putting all of your unit tests in your src folder is clutter and file size. Some people complain that their project explorer becomes too cluttered when they put spec files right in with the application code. Whenever I look at their code it's almost always the case that they aren't breaking things down as much as they could (or should) be. It's important have your directories broken down by components. Your routing will give you logical points to break up "pages" into different files, and from there you should be breaking down things on the pages into separate components .
Keeping the Build Small
I wasn't totally sure that this piece of code was really solving the "big build problem", but indeed Mathieu Lux himself (creator of gulp-angular) confirmed this:
Original thread on github: https://github.com/Swiip/generator-gulp-angular/issues/1131#issuecomment-222609136
So, there you have it. Any file that ends in a ".spec.js" or ".mock.js" will be not be injected into the final production build files.
But What About That e2e Directory?
This is a question that people often ask me, and I just wanted to address it here. They say, "Wait a minute. For unit tests you recommend putting the 'spec.js' files right in with all the other code, but then when we start doing e2e tests you put a new folder on the same level as app, just like the old 'root tests folder' method that you say was such a bad idea!".
I like when people ask me this question because it means they're really thinking. It seems contradictory at first, but here's the thing- there's a fundamentally different strategy for how these two types of tests are written. Unit tests are something that I like to do in a TDD style, writing the tests and application code basically at the time time. Thus, they organically grow from a single spot in your codebase. Protractor tests can make api calls, touch databases, do file i/o, etc. and so they aren't fast enough to run with a watch flag (Note how there exists a gulp test:auto command but not a gulp protractor:auto command). Also, unit tests are very concerned with the methods and properties of the Angular objects under test so you will mostly like be flipping between your *.js file and *.spec.js file often; hence the reason why they are next to each other. Protractor tests, on the other hand, are more after-the-fact tests. Although I am a strong believer that programmers writing e2e integration tests is a good thing (rather than a less coding-focused test engineer writing them), I don't know anyone that writes Angular protractor tests in a TDD format. The approach I take is to develop unit tests and application code with TDD, and then when it's done I'll throw protractor tests on it just to make sure it's perfect (and to have something for the CI tool to run on various browsers).
Let's Not Be "Scolling Like Crazy". Thanks.
What Do You Think?
Do you put your unit tests right in the src folder? Do you even write unit tests? :)
Let me know your thoughts and any concerns you have in the comments below!
The posts on this site are written and maintained by Jim Lynch. About Jim...