Add unit tests about ladder99

[MRIIOT]

I would be OK with meter. @tukusejssirs go for it.

[MRIIOT]

What are some examples of currently existing tests?
What are some examples of critical areas?

[bburns]

we don't have much in the way of tests yet - just some *-test.js files that run in node that were used to help develop the code, not geared towards automation.

critical areas would be any complex/confusing code - eg the jobboss shift handling, availability shift handling, adapter cache calculation code

could start by instrumenting that code for tests. along the way help make code more functional and easier to understand.

and for future code, i haven't had much luck sticking with TDD in other projects, but could try that going forward. @tukusejssirs what about you?

[tukusejssirs]

and for future code, i haven't had much luck sticking with TDD in other projects, but could try that going forward. @tukusejssirs what about you?

IMO having tests for all units (at the very least functions and methods) would be very nice, however, it takes some time to create robust tests. We could even track the test coverage.

While I was thinking about using TDD approach, however, I am more acustomed to be create the code first, then tests (after the code is more or less ready to merge, before merging), as the code change and while coding, I can create a list of test cases (based on the conditions in the code), which I can’t create out of the blue before the code is built.

IMO, we should try to add tests whenever when add new features or update (enhance, possible fix some bugs) the code. Or we could wait until a particular app is moved to Nx, then start adding the tests. In either case, there is no need to add all the unit tests systematically right now, as we don’t have the manpower for that right now.

[MRIIOT]

@bburns TDD requires specifications up front. It won't work without spec or design model.
@tukusejssirs Acceptance tests might be an option.

[bburns]

IMO, we should try to add tests whenever when add new features or update (enhance, possible fix some bugs) the code. Or we could wait until a particular app is moved to Nx, then start adding the tests.

Okay - it makes sense to start adding tests for new features after we move services into Nx, since it includes Jest.

Could start with the Meter service, since we'll be adding code for OEE there.

[tukusejssirs]

Could start with the Meter service, since we'll be adding code for OEE there.

Yeah, I was about to ask you which app (service) would be (in your opinion) the easiest to move to Nx workspace first. I was thinking about one that does not depend on ther services (so that it could be easily tested without Docker). Moving the app itself is the easiest part, we need to adjust (a bit) global Nx config and probably the project-level config too. There are so many options …

Do you think that meter is the ‘right’ service to start the move to Nx? I was thinking about creating a test branch in my fork and then I’ll you guys for comments if my choices will be okay with you. WDYT, @bburns, @MRIIOT?