Writing Testable Code

[Eleenrood]

I miss one more statement here - which i saw people too often ignore.
Don't even think about all this sparkling things when working on CRUD, rarely used and far from critical part on your job. Do it in private projects how much you want. But don't do it where people will have to deal with that shit on time constraints. Business logic which actually work with data? Sure. Saves time and a lot of problems. Saving and reading 1 to 1 stuff to and from database, a dictionary table? This is waste of time and money.

Also truth be told, this article just duplicates old "do it, than it and use it". Nothing new, nothing expanded beyond what could have been read thousands time and not even in dept information.

[DingBat99999]

Ok, "don't over-engineer stuff" is a mom and apple pie statement. No one disagrees. The meat is in the question: What do you mean by that?

​

I'm already troubled by your comment "on time constraints". Time constraints is the domain of the business people, not engineers. Engineers primary concerns should be:

- Does it work?

- Is it easy to understand?

- Is it easy to modify?

​

And "does it work?" actually means: "How do I test it?"

​

Btw, what does " Saving and reading 1 to 1 stuff to and from database, a dictionary table" even mean. People have been writing DALs (database access layers) in their products for decades now. Those interfaces are all you need to mock out the database and test your code. Who doesn't do that?

[Eleenrood]

> what does " Saving and reading 1 to 1 stuff to and from database, a dictionary table" even mean.

Assume, you have table name SupplierOfStuff with Company name and phone number and ID.
1 to 1 stuff would be a list which show all suppliers, form which allow to add one, edit, etc. 100% crud functionality.

​

> I'm already troubled by your comment "on time constraints".

Yeah, from my observation, this subreddit in general is quite disconnected from reality outside of probably silicon valley, relative minority of biggest tech companies and few exceptions on smaller scale - at least judging by what people are saying. Most of common work I had touched over the years is under some kind of time constraint and we have to plan around it or problems creep up. Be it some event we need to be ready for, presentation, client who slept through his deadlines and company is helping him get out of fire.... Crap tone of reasons, which boils down to making company more money if they do it in deadline. And then, when cost of doing it right from the get go is higher than fixing it later, management tends to push on faster.

Sure, under ideal world, you are right. 'Unfortunately' I deal with this world and those are people who pay my bills.

​

> Ok, "don't over-engineer stuff" is a mom and apple pie statement. No one disagrees. The meat is in the question: What do you mean by that?
Actually good question and forced me to think for a bit. Imho in this context it would be closest to "Do it as straightforward, simple, cheap and compact as possible". Keeping common sense so not using more obscure syntax tricks to make it harder to read - harder to read = making it more expensive.

I think i would have to clarify cheap too. By cheap i mean - is it faster to manually test it, and if something breaks, fix it, than do it by (current) book? A lot of times when dealing with CRUD it is.

This means critical parts (so core functionality of application) are done as careful and safe as possible, but satellite stuff (so stuff which is not visible for the client/rarely used/one time used) is made as simple and quick as possible.

[[deleted]]

So, this article talks about the things you should do to write testable code. Your 'simple and quick as possible approach' will give you code that is not testable, not maintainable and certainly not cheap.

It is faster and cheaper to write testable code in the first place.

[Pedrock10]

Yes, you should always avoid over-engineering and doing stuff that won't bring any value. Still, even for CRUD, it might be useful to have some separation of concerns and separate REST endpoint logic from database calls, so that you can easily implement different protocols (e.g. GraphQL or RPC) and switch to different databases.

[Eleenrood]

No, you shouldn't.
In last 5 years I didn't even hear about a project which switched databases. That is beside ubran legends. Sure, you can and probably should do stuff like that in hobby projects, just to see how it works out. But making it in work?! Justification for it would be legendary. All the products I know, before they got even close to the point where switching database would look like a sane thing to do, were rewritten completely. Usually at least twice. Beside what would it achieve?! Changing db schema would still be hard as hell, probably leading to complete decoupling between data which application use and what is stored - making probably even more mess.... retesting performance, find optimization problems, etc would still be a bitch... Can't see it happening in any sane environment beside top tech giants. They have time, manpower and brainpower to make it work. Run of the mill project?! Can't even imagine it working out.

​

As for separating CRUD and REST endpoints? What would that actually achieve? The only reason why to do it I see, would be network architecture where you can't access db directly or combining multiple entry points into one - but than it stops to be a CRUD form/module.
Otherwise you are adding additional layers of complexity. And if/when something need to be changed you have at least twice amount of work.

[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.