My view would be that if you are struggling to get useful information out of tests to that extent, then your black boxes are too big!

I agree that there's nothing worse than a test that says "your stuff broke" and provides no additional information why. But there's a balance between that, and testing the internals of an implementation.

Because tests should not be more verbose than code. Refactoring the sumArray method to use map instead of a for loop shouldnt break tests. it is terrible terrible practice to take internal implementations and then stub their callees to make sure that the code that was written got executed. I saw this a lot at Amazon. Its a fundamental type of moronic testing and is absoltely useless. All it serves is to make any kind of refactoring or changes twice as burdensome.

Any yet it's extremely valuable when you want to test code that deals with externalities (aka, i don't need to actually insert a row into a db over the wire to make sure my biz logic works, and in some cases like error handling testing, it'd be way harder to actually code the situation rather than to simulate it), and tends to give you a baseline set of reassurance that can run very quickly. So IDK about just hauling off and labeling it as "moronic".

checking for an insert into the database in the most general fashion is okay. checking for the exact dynamic data?? you are basically copying your code.

I'm just saying I can cut test time dramatically by not testing that X db actually can do it's job in expected ways, and those tests can run sans networking and unexpected situations won't cause false negatives. Both things are fine and they go very well together but each allows you to do different things

exact tests on implementation at the "db was updated properly" category are usually classified as integration tests. theres nothing wrong with those. but one shouldnt test specificity of internal method code for small units.

> Refactoring the sumArray method to use map instead of a for loop shouldn't break tests.

What kind of test could you possibly write that would break because of this? Something that measures time or memory usage, or uses reflection?

If you have clearly defined interfaces between significant internal components (which you should), why not test that they do what you ask? Public vs. internal is often more about what is exactly the client of the code, not the code's function or structure itself.

A stub on the iterator interface would do it..but like I said..terrible use of testing