NS&I accounts to snap up now - and the duds I'd avoid at all costs: SYLVIA MORRIS
All the tricks that will get you into VIP airport lounges for less this summer - even if you've booked economy
Virgin Media handed £28m fine by Ofcom for preventing contract cancellations
'An overwhelming vindication of our journalism': Prince Harry's phone hacking case against the Daily Mail is dismissed in full
CodeSOD: Module Test
TJ inherited a NestJS project. The original developers left the team many years ago, but they've left their mark in the codebase.
// ProjectsModule.ts @Module({ controllers: […], providers: […], exports: […], }) export class ProjectsModule {}NestJS is a dependency-injection oriented framework for TypeScript code. It offers "providers" (dependencies that can be injected), "controllers" (as one would expect), and lets you bundle them together into "modules". Modules can depend on other modules, letting you build a modular and flexible graph of dependencies. This means that the empty module isn't wrong here.
No, for it to be wrong, we need to write some tests:
// ProjectsModule.test.ts describe("ProjectsModule", () => { it("can be created", () => { const projectsModule = new ProjectsModule() expect(projectsModule).toBeTruthy() }) })Since modules are just containers for related code objects, there isn't much to test here. While "dynamic modules" which execute code are a thing, they don't execute that code at construction time anyway. This test will always pass. It isn't a test, it doesn't do anything. It likely doesn't even get their coverage up, since whatever providers or controllers it's referencing aren't covered by this test. It's a test that tests nothing but the framework it runs on top of.
"At least there are tests," TJ writes.
[Advertisement] Picking up NuGet is easy. Getting good at it takes time. Download our guide to learn the best practice of NuGet for the Enterprise.