• Dennis (unregistered)

    This looks a bit like the old Angular pregenerated tests, and (at least in Angular) actually DO test something: that injections has been configured properly.

    Now (in Angular) you're supposed to configure the testbed separately, instead of using the project configuration, so all you are really testing is still your test setup.

  • Marty (unregistered)

    Actually, such tests do serve a purpose: in TDD, you are writing a test before any code, and this test then obviously and immediately fails because there is no such module. Then you are writing the code itself, and as soon as the module exists, the test succeeds, and you have verified a number of things:

    • a module with the expected name exists
    • the module file is contained in your deployment
    • the module can be instantiated
    • etc.

    No WTF at all IMO.

  • (nodebb)

    Having worked with buggy (or at least ill-documented) frameworks in the days before unit testing was commonplace, one heck of a lot of discovery about the framework occurred via debugging hard-to-reproduce bugs.

    Had unit test harnesses existed then I could see spending about 6 man-months building tests to explore the framework's corner cases. Not that we could fix any of them, but at least we'd learn which cases to code around.

  • 516052 (unregistered) in reply to WTFGuy

    Yea. If I had a cent for every time I had to figure out the bugs and edge cases of a supposedly working API the hard way and code around them I'd have enough to retire. Well, I am retired, kind of. But I could retire again.

  • Brian (unregistered) in reply to Dennis

    Yeah, the last C# project I worked on did something similar - it had a set of tests using reflection to walk through all the classes in a module and instantiate them, specifically to test dependency injection. And it did catch errors every now and then when someone forgot to register a dependency. (The other unit tests wouldn't catch this because they directly created objects with mocked dependencies instead of the runtime ones.)

    Don't know NestJS well enough to say whether that's the intention here, but it is a worthwhile test to run.

  • (nodebb)

    Who tests the tests?

  • (nodebb)

    Worthless test are the worst kind of technical debt. Boy are they a pain in the butt to get rid off since you have to go against the "but maybe they actually do something somehow sometime somewhere..." argument - often uttered by clueless managers.

  • (nodebb) in reply to Marty

    While I'm sure the main WTF is meant to be how code and tests that do nothing made it to production, your comment triggered a bit of a rant. I frequently hear how awful TDD is because most people miss a key point: tests are for contracts - the things you've promised - not for implementation. If I contract with you to mow my lawn, I'm going to expect that when you are done the grass will be all the same height, and nothing but the lawn has been cut. I might care how long it takes, but I don't care what size or brand of lawnmower you used. If I want stripes on my lawn I might need to check them as well, but I don't need to know if you went left-to-right or right-to-left to make them. That a module exists and can be instantiated should be tested by being used. I could have a test that asks for a project list, and when the implementation needs to reference the ProjectsModule, it will fail if the module is not available, fails to instantiate, etc. If you are writing tightly-coupled tests like this, you are losing the main benefit of TDD - the ability to quickly change code and know it still works without spending more time on tests than on code.

  • (nodebb)

    It's hard to say with this isolated code snippet, yet this looks exactly like the kind of template I'd keep around to then duplicate when I want a new module and a test skeleton for it.

Leave a comment on “Module Test”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article