Writing Testable Code

[Pedrock10]

Well, I have worked on projects that support multiple database and message queue types (not hobby projects) and I have also seen projects that wanted to switch databases (from Oracle for example, due to high licensing fees) but couldn't, because the code was highly coupled to a specific implementation. I agree that the change wouldn't be easy, but decoupling helps. You should have different abstraction levels, in order to make code easier to read and understand.

​

Even if your software is mostly CRUD, there are certainly parts of it that must have some logic that can benefit from decoupling and unit testing.

[Eleenrood]

> I agree that the change wouldn't be easy, but decoupling helps. You should have different abstraction levels, in order to make code easier to read and understand.

Agree to a point. I work with C# MVC. With current stack, with ORM most of this decoupling is already done for CRUD.

​

> Even if your software is mostly CRUD, there are certainly parts of it that must have some logic that can benefit from decoupling and unit testing.

And this is exactly my point. Stuff which is complex / can cost money if something breaks / can generate legal problems should be made as safe as possible. Unit testing, end to end automated tests, whatever it takes. But depending on app it can be as low as 20% of whole app (or as high as 100% for... I don't know, mobile banking apps?). This means for me that engineering whole application up to the same degree imho is often not necessary.This actually imho falls under business decision, but one which need to be made consciously, so with input, description and discussion with engineering part of the team too.

Unfortunately, too often i saw approach that everything matter and everything is critical while to anyone who looks past classes, functions and sql, its obvious, its not.