5 ms·

Wow, people are still writing more and more words on unit testing with absolutely no new ideas. Nothing to see here. Move along.

rbanffy 17y ago
Quite the contrary. This attitude in a MSDN blog, from a Microsoft employee explain a lot of problems their users have. Way to go, Microsoft. Testing is for sissies! Real Men write correct code. Now I can use Exchange and know why it sucks so bad.
- MartinCron 17y ago
  What one random developer writes on his MSDN blog doesn't mean anything more than what any other random developer writes on an MSDN blog. Microsoft is way too big and has way too many developers to draw conclusions like that. I've done consulting work for Microsoft, and I've never conceptualized them as one company with one voice. Microsoft is more like lots and lots of little companies which run the entire spectrum from total dysfunction to jaw-dropping awesomeness.
- j_baker 17y ago
  "Testing is for sissies! Real Men write correct code." I seriously laughed when I read this. I'm willing to sacrifice the extra couple of inches of programmer penis size by writing tests.
  - rbanffy 17y ago
    You can also refrain from writing the bugs ;-)
  - forensic 17y ago
    But the tests themselves _are_ code. Do you have tests that check the tests? And then tests that check the tests that check the tests? At one point or another you just have to learn to live with bugs.
    - rbanffy 17y ago
      And even if all code is provably correct, there is always the chance of a random particle hitting a transistor in the chip and clearing a bit that should be 1.
      - forensic 17y ago
        Just like in math, even if the code is provably correct, there is always the possibility someone screwed up the proof. In the end it always comes down to writing the least buggy software possible and then bug zapping. Having debug tools is smart of course, but TDD goes a bit further than debug tools. When I write unit tests I don't think of them as unit tests I think of them as debugging probes.
        rbanffy 17y ago
        Have you noticed that there is an uncanny number of downvotes in this whole topic?
- snprbob86 17y ago
  This is the opinion of a single engineer on a single team. There are tens of thousands other engineers and thousands of other teams. My team (at Microsoft) is religious about unit tests for some parts of the product (math libraries, content serialization logic, etc) and have a grand total of zero "unit tests" for other components (some UI, etc). We do, however, have a full test team who write numerous automated regression tests as well as conduct significant manual testing and routinely use the product. Furthermore, have you read it? It's not saying don't write tests. It's saying that TDD is not a silver bullet.
  - rbanffy 17y ago
    I am sorry. I was being cruel. It may not be a silver bullet, but it's the kind of "don't leave home without it" ammo any self-respecting programmer will keep close all the time. Without them the risk of regressions is immense.
    - snprbob86 17y ago
      You're making far too many assumptions about the code to be tested. The folks who wrote our math libraries (primitives such as 4x4 matrices, vectors, planes, spheres, axis-aligned boxes, etc), would agree "don't leave home without it" for TDD. The folks who wrote our drawing libraries cheat on the TDD a bit and write the code first, then capture a screenshot and use that screenshot for automated testing to verify nothing breaks in the future. The folks who wrote the sample code that implements a simple game (involving math and graphics) laugh at the concept of TDD. What would you possibly test? There is no `bool IsFun(Game)` function. How should Mario jump? I dunno, just pick some random numbers and math operations until it feels like it works. Then try not to break it. The interesting bit here is that each of these groups of folks are on the same team, in fact many are the same people. Use the right tool for the job. Invest your testing efforts where you get the most bang for buck.
      - rbanffy 17y ago
        Using a screen capture is not exactly cheating. It's automating regression testing and that's a Good Thing. A human ensures the first implementation is correct and then the tests ensure future implementations are correct too. There is also stuff that could (and should) be tested - like a drawing primitive that should not exceed a given region, a pixel that should be of a given color or even an operation that should finish in a given number of cycles for a given pixel count. Erroneous arguments should also be tested as the proper exceptions should be thrown (or, at the very least, proper error codes should be emitted). For those who write the demo code, there is a lot of tests to do on the gameplay itself - collisions detection, rendering tests, physics and a whole lot of stuff that will also serve as nice documentation on how to use the components that are being exercised.

rbanffy 17y ago

Quite the contrary. This attitude in a MSDN blog, from a Microsoft employee explain a lot of problems their users have. Way to go, Microsoft. Testing is for sissies! Real Men write correct code. Now I can use Exchange and know why it sucks so bad.

MartinCron 17y ago
What one random developer writes on his MSDN blog doesn't mean anything more than what any other random developer writes on an MSDN blog. Microsoft is way too big and has way too many developers to draw conclusions like that. I've done consulting work for Microsoft, and I've never conceptualized them as one company with one voice. Microsoft is more like lots and lots of little companies which run the entire spectrum from total dysfunction to jaw-dropping awesomeness.
j_baker 17y ago
"Testing is for sissies! Real Men write correct code." I seriously laughed when I read this. I'm willing to sacrifice the extra couple of inches of programmer penis size by writing tests.
- rbanffy 17y ago
  You can also refrain from writing the bugs ;-)
- forensic 17y ago
  But the tests themselves _are_ code. Do you have tests that check the tests? And then tests that check the tests that check the tests? At one point or another you just have to learn to live with bugs.
  - rbanffy 17y ago
    And even if all code is provably correct, there is always the chance of a random particle hitting a transistor in the chip and clearing a bit that should be 1.
    - forensic 17y ago
      Just like in math, even if the code is provably correct, there is always the possibility someone screwed up the proof. In the end it always comes down to writing the least buggy software possible and then bug zapping. Having debug tools is smart of course, but TDD goes a bit further than debug tools. When I write unit tests I don't think of them as unit tests I think of them as debugging probes.
      - rbanffy 17y ago
        Have you noticed that there is an uncanny number of downvotes in this whole topic?
snprbob86 17y ago
This is the opinion of a single engineer on a single team. There are tens of thousands other engineers and thousands of other teams. My team (at Microsoft) is religious about unit tests for some parts of the product (math libraries, content serialization logic, etc) and have a grand total of zero "unit tests" for other components (some UI, etc). We do, however, have a full test team who write numerous automated regression tests as well as conduct significant manual testing and routinely use the product. Furthermore, have you read it? It's not saying don't write tests. It's saying that TDD is not a silver bullet.
- rbanffy 17y ago
  I am sorry. I was being cruel. It may not be a silver bullet, but it's the kind of "don't leave home without it" ammo any self-respecting programmer will keep close all the time. Without them the risk of regressions is immense.
  - snprbob86 17y ago
    You're making far too many assumptions about the code to be tested. The folks who wrote our math libraries (primitives such as 4x4 matrices, vectors, planes, spheres, axis-aligned boxes, etc), would agree "don't leave home without it" for TDD. The folks who wrote our drawing libraries cheat on the TDD a bit and write the code first, then capture a screenshot and use that screenshot for automated testing to verify nothing breaks in the future. The folks who wrote the sample code that implements a simple game (involving math and graphics) laugh at the concept of TDD. What would you possibly test? There is no `bool IsFun(Game)` function. How should Mario jump? I dunno, just pick some random numbers and math operations until it feels like it works. Then try not to break it. The interesting bit here is that each of these groups of folks are on the same team, in fact many are the same people. Use the right tool for the job. Invest your testing efforts where you get the most bang for buck.
    - rbanffy 17y ago
      Using a screen capture is not exactly cheating. It's automating regression testing and that's a Good Thing. A human ensures the first implementation is correct and then the tests ensure future implementations are correct too. There is also stuff that could (and should) be tested - like a drawing primitive that should not exceed a given region, a pixel that should be of a given color or even an operation that should finish in a given number of cycles for a given pixel count. Erroneous arguments should also be tested as the proper exceptions should be thrown (or, at the very least, proper error codes should be emitted). For those who write the demo code, there is a lot of tests to do on the gameplay itself - collisions detection, rendering tests, physics and a whole lot of stuff that will also serve as nice documentation on how to use the components that are being exercised.