First-class testing
Truong Hoang Dung

Truong Hoang Dung @revskill10

About: I hate technical debts, very much. Learning to clean debt out of my life.

Joined:
Aug 2, 2018

First-class testing

Publish Date: Jan 27 '19
6 9

Some years ago, i saw some frameworks like Ruby on Rails trying to put tests folder in the same folder with dev codebase.

What's wrong with this approach ?

  • Gemfile is becoming a mess with testing , dev and production dependencies.
  • Discourage dependencies de-coupling, which means we're encourage to put everthing in the same place for the ease of "directory traversing"
  • The codebase now is easier to "break", because for some reason, both tests code and dev code live in the same place, so they must please each other.

The main disadvantage with this approach, is that: Testers are afraid to write tests ! They're touching the main codebase!

I see the same problem with many frameworks in other languages also.

"Stop putting tests folder in the same codebase with dev folder"

So what does "First class testing" mean ?

Treat your tests folder the same role as dev folder, with its own dependencies, team ownership, development (tests is code), deployment (tests is code, so it could be compiled for deployment)

I'm happy with this approach and i found testing is easier to verify some weird behaviour in the main codebase.

What's your favorite testing strategy ?

Edit: My project structure:

Comments 9 total

  • Michael
    MichaelJan 27, 2019

    Can the same be said of documentation for a project?

    • Truong Hoang Dung
      Truong Hoang DungJan 27, 2019

      Sure. Treat the docs as first-class also. I'm going to post the exact post about docs soon.
      Thanks for reminding me !

      • Michael
        MichaelJan 27, 2019

        Looking forward to reading it! This was exactly something I was wondering about. I often find it hard deciding when to break up a small test project from notes and testing.

  • Frank Puffer
    Frank PufferJan 27, 2019

    Yes, tests need to have their own folder structure for exactly the reasons you mentioned. I also do it that way. But I always have the feeling I am doing it wrong.

    One of the most important rules in software design it to put things together that belong together. And a test and the tested class definitely belong together.

    Especially, it is no good idea to create separate trees with the same structure because they are hard to maintain.

    The same issue occurs in other areas of software development as well, like header and implementation files in C++ and, as Michael wrote, documentation and specifications.

    Sure, there are IDEs and other tools that support you in keeping the different structures consistent. Still I can't get rid of the bad feeling.

    • Truong Hoang Dung
      Truong Hoang DungJan 27, 2019

      I guess it's more about convention rather than a rule. Different projects have different convention about project structure.

      • Frank Puffer
        Frank PufferJan 27, 2019

        Maybe "rule" is not a good term. I should have better written "principle". What I actually meant is that whenever you try to structure anything, not only software projects, it is important to keep cohesion strong while keeing coupling weak. Otherwise you will likely end up with an unmaintainable mess. This is a very basic principle and not just a convention.

        • Truong Hoang Dung
          Truong Hoang DungJan 27, 2019

          In that case, DHH (author of RoR) would swear at you that: Look at basic RoR project structure ! It uses Convention over Configuration and it worked well for us over 10 years.

          What works in practice is what's right. Not theory.

          • Frank Puffer
            Frank PufferJan 27, 2019

            What works in practice is what's right.

            Agreed. And that's where theories and principles come from. If they no longer match reality, we need to modify or at least extend them. It's called the scientific method.

  • ItsASine (Kayla)
    ItsASine (Kayla)Jan 28, 2019

    Unit tests with the code they are testing (I would expect to see thingy.component.js with thingy.component.spec.js in the same directory with the rest of the thingy stuff).

    Integration and end-to-end tests I put first class, though working in Javascript, I tend to share the same package.json across all of them. If unit tests and end-to-end tests both use Jasmine, I don't want to have that in two different node_modules.

Add comment