Hacker News Reader

Comment by mbreedlove | Hacker News Reader

I think the biggest problem with TDD is that there are two types of code, trivial and non-trivial.

I think testing trivial code is a waste of time and does nothing but improve coverage numbers.

When you think about a non-trivial problem to write tests, you don't always know what the final code will look like. 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.

View on HN

What happens where trivial code later needs to grow? What happens when trivial code is invoked by non-trivial code and you need to make a change?

If it's truly trivial code, you should be able to test it trivially, so I'm a little unsure of why this becomes a make-or-break issue for some people. Pretty sure more time and energy is wasted determining if code is trivial and needs to be tested versus just testing the damned thing ;-).

Trivial code does not grow, it gets replaced. If the replacement is non-trivial, test it. If it's trivial, don't. Anyway, you've saved some useless tests that would need to be rewrite on the first change.

Trivial tests may be trivial, but they are numerous: their need grows exponentially with code size. And they generate almost all the false positives you will get.

Tests are code and code is a liability.

The DirectX12 api is non-trivial code; their testing has little in common with TDD.

Depends what you use to categorise something as trivial - some functionality may be trivial technically but have an incredible impact on end users. Is that trivial or non-trivial?

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.

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.

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

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?

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.

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.

Reply on news.ycombinator.com