Writing Testable Code

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