5 ms·

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 not

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.

matthewmacleod 10y ago
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.
- nrinaudo 10y ago
  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?
  - goldenkek 10y ago
    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.
  - matthewmacleod 10y ago
    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.
- dagw 10y ago
  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.
  - goldenkek 10y ago
    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.
    - johncolanduoni 10y ago
      > 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.
      - goldenkek 10y ago
        A stub on the iterator interface would do it..but like I said..terrible use of testing
    - awinder 10y ago
      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".
arethuza 10y ago
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?
awinder 10y ago
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 ;-).
- theparanoid 10y ago
  Tests are code and code is a liability. The DirectX12 api is non-trivial code; their testing has little in common with TDD.
- marcosdumay 10y ago
  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.

matthewmacleod 10y ago

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.

nrinaudo 10y ago
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?
- goldenkek 10y ago
  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.
- matthewmacleod 10y ago
  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.
dagw 10y ago
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.
- goldenkek 10y ago
  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.
  - johncolanduoni 10y ago
    > 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.
    - goldenkek 10y ago
      A stub on the iterator interface would do it..but like I said..terrible use of testing
  - awinder 10y ago
    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".

arethuza 10y ago

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?

awinder 10y ago

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 ;-).

theparanoid 10y ago
Tests are code and code is a liability. The DirectX12 api is non-trivial code; their testing has little in common with TDD.
marcosdumay 10y ago
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.