Jim Lynch Codes
  • Blog
  • About Jim

Writings about one coder's stories & experiences.

Why I Recommend Unit Tests in the Src Folder

5/31/2016

0 Comments

 
Let's talk about unit tests and directory structure. If you're doing it right you're going to be creating at least one test file for every JavaScript file you create so it's a given that there are going to be quite a lot of tests. Where do you put all of these tests? There are basically 2 schools of thought here. In this post I'll explain the two theories and then put forth an argument for why you should be putting unit tests in your src folder. 

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:
Picture
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:
  • You can easily ensure all javascript files have a corresponding test file.
  • You can easily switch between the test file and app code file.
  • It's easier for command line generators to create code and spec files for you this way.
From a developer perspective, it's way nicer having tests right in with the source code, but is this method actually all-around better?

Preventing Clutter

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

Another potential problem when putting tests files in the src folder is that the test files might get bundled up into the finished build. Although this isn't a huge deal, for large projects it is pretty wasteful to be adding file size to your build when that test code will never, ever be used or seen from anything the end user does with the application. In the good old days when Java was the poppin' technology and everyone was into JUnit, the simple solution was to just put your tests outside of the src folder. Nowadays, we have much more sophisticated and configurable build processes for JavaScript projects. If you are using the Gulp-Angular yeoman generator that I'm always recommending then you might have noticed this block of code in the inject.js file inside of the gulp directory: 
var injectScripts = gulp.src([
    path.join(conf.paths.src, '/app/**/*.module.js'),
    path.join(conf.paths.src, '/app/**/*.js'),
    path.join('!' + conf.paths.src, '/app/**/*.spec.js'),
    path.join('!' + conf.paths.src, '/app/**/*.mock.js'),
  ])
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:
Picture
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!".
Picture
The out-of-the-box directory structure for Gulp-Angular generator.
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.

Here the key thing to realize about using the n00b structure for your project. If you have once huge folder for css, one for JavaScript, one for templates, one for unit tests, one for e2e tests, etc. then just imagine what doing actual work will feel like. If you have tons of parallel directory structures in a large app and you just want to work on one thing it's going to be a nightmare just to open up componentA.html, componentA.js, componentA.spec,js, componentA.scss, etc. If you're working on Component A then you will most likely want these files open. Why make it incredibly hard on yourself? Why force yourself to be scrolling like crazy through your project explorer panel just to open up the files for a single component? I've worked on these scrolling like crazy projects, and yes, it sucks! I have a motto for directory structures, and it is this- "If you're scrolling like crazy, you're doing it wrong".

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!
​Cheers, Jim.
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    ​Author

    Picture
    The posts on this site are written and maintained by Jim Lynch. About Jim...
    Follow @JimLynchCodes
    Follow @JimLynchCodes

    Categories

    All
    Actionscript 3
    Angular
    AngularJS
    Automated Testing
    AWS Lambda
    Behavior Driven Development
    Blockchain
    Blogging
    Business Building
    C#
    C / C++
    ClojureScript / Clojure
    Coding
    Community Service
    CS Philosophy
    Css / Scss
    Dev Ops
    Firebase
    Fitness
    Flash
    Front End
    Functional Programming
    Git
    Go Lang
    Haskell
    Illustrations
    Investing
    Java
    Javascript
    Lean
    Life
    Linux
    Logic Pro
    Music
    Node.js
    Planning
    Productivity
    Professionalism
    Python
    React
    Redux / Ngrx
    Refactoring
    Reusable Components
    Rust
    Security
    Serverless
    Shell Scripting
    Swift
    Test Driven Development
    Things
    TypeScript
    Useful Sites
    Useful Tools
    Video
    Website Development
    WebStorm
    Writing

    Archives

    August 2021
    February 2021
    January 2021
    October 2020
    September 2020
    May 2020
    April 2020
    February 2020
    January 2020
    December 2019
    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015

    RSS Feed

  • Blog
  • About Jim
JimLynchCodes © 2021