Developing for testability: BL- and CS modules
Question

Hello community!

I'm ambivalent regarding what type of business logic should be performed in CS vs BL modules. I tend to only put entities, CRUD actions and validations on user input in the CS module, while in the BL modules, I put more advanced business logic (calculations etc), as well as orchestrating calls to several server actions in the CS module.

Now, regarding for instance the Single Responsibility principle and the likes, I find this a good approach. However, I find that when I write Unit Tests for my CS module's actions, I'm not completely covering the code. Say, for instance, that I have an action in my BL module that first calls an action in the CS module to change an report's status to approved, and then another action in the same CS module that removes some metadata that should not be present in approved reports.

If the action calls were made to different CS-modules, this would be a no-brainer; but in this case, with the actions being in the same CS module, would it be considered overkill to extract the business logic to the BL module? If it was all grouped together in one action in the CS module, I would be able to test it through a unit test; however, I'm not sure I would consider such an action a "unit" in the actual sense of the word, and I would violate the Single Responsibility principle.

Then again, I would like to cover the expected business behaviour in my tests...

Any input on how to approach this? Should BL modules only contain orchestration calls to different core modules, or should they be viewed as an isolated repository for all business logic to increase code isolation and readability? Should BDD Framework unit tests cover business logic?

Hi Johan,

i structure my CS modules as you described it already. In my CS modules i have entities and crud server actions. For create and update actions i also perform all sorts of validation to ensure that data is written to the database in expected format (eg. RegEx patterns asf). My guideline is "CS modules are closer to data".

Wheres BL modules i treat "Closer to the consumer". Besides aggregating multiple CS modules in a BL module i create my server actions around business concepts. In form of "I want to do....." eg. Claim_SetStatus or Claim_AddParty. My BL modules also contain Data Retrieval actions eg. Claim_GetAllClaims or Claim_GetParties along with filter asf. (that is my personal preference, especially when i have the need to add some sort of access control entry based data retrieval).

Best

Stefan

Thank you for your input!

Yes, I'm approaching things basically the same way you are. Very nice and illuminating explanation though, gives me more perspective on, and arguments for, this approach :)

And, if I may ask a follow-up question, are you concerned that your BL module logic is not covered by unit tests (if you implement them)? Or would you write unit tests for your BL module code as well, even though those actions might be considered one level above the basic "units" that are being tested?

To be honest i only create tests for the business logic actions (including the data retrieval actions), as i structure my modules in a way that a consumer only consumes from the BL (or most likely an API module on top of it), which itselfs uses the CS actions asf "under the hood".

Very interesting. I've refrained from testing BL logic with the BDD framework, as I've considered such logic to be leaning more towards end-to-end- than component testing. However, since I can't find a viable option for performing end-to-end tests, I'll definitely look into using your approach. Thanks again for valuable input!

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.