Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

Maybe you forget an edge case or some small detail in the requirements that will cause you to restructure the code and approach the problem in a different way. In which case, you now need to re-write your tests. You might as well just write tests around the final version.

Maybe, but I'd wager on the whole that you probably don't. Your surface API should be the same, and you shouldn't be testing internal implementation anyway. If you write clear and consistent interfaces, then forgetting a requirement will mean adding a test – not rewriting them.

View on HN

you shouldn't be testing internal implementation anyway

Why not? When my big black box stops giving me the expected answers I want to know exactly which cog inside that box that broke.

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.

> 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

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.

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.

What do you mean, you should not be testing internal implementations anyway? Does that also mean you don't do unit test, only integration or end-to-end ones, because unit tests are tests of the internal implementation of your software?

He means you test pure functions and mutations. You dont stub data sources that your implementations use to see if they were called. tests need to be about enforcement of correct interface exposure. not exact implementations. its one of the most facepalm types of useless testing that ive seen littered around Amazon's Seattle teams due to these Indian managers wanting to make sure the data sources called in every method actually got called and that there is 100% coverage. serves no purpose except to basically make two copies of the code..the test as a doppleganger of the actual code but using stubs.

Not quite – most projects have internal interfaces which are relatively stable, and tests should be against those, rather than the internal implementation of those modules.

Unit tests are great, but they should still be testing at the boundary of code modules – if changing the internal implementation of that module breaks a test, it probably isn't testing at the correct level.

Reply on news.ycombinator.com