5 ms·

> Two completely different devices, each responsible for checking the other, deviated identically for vastly different reasons. Happens frequently. “The tests

> Two completely different devices, each responsible for checking the other, deviated identically for vastly different reasons. Happens frequently. “The tests are broken but I’m positive the software is correct so I’m going to fix the tests”

Armisael16 7y ago
That isn’t at all what happened.
VBprogrammer 7y ago
That's one reason I hate complexity in tests. Your tests have to be dumb enough that you are 99% sure the code under test is at fault.
- WrtCdEvrydy 7y ago
  By definition, tests have to be more complex than the underlying code. The test have to setup the conditions, execute the action and validate it. Don't confuse complexity with shitty unreliable tests (timing-based tests)
  - penagwin 7y ago
    Depends on the type of test. What you guys are talking about are unit tests, and are designed to test individual methods/functions. You write a separate test for each one. There's other types of testing, integration tests sound like what you are both complaining about. Integration tests test the interaction between components of a system, and are thus far more complex and likely to break as you're developing (which is a huge pain). However integration tests have their place - just because the function works doesn't mean it's being called from the web client correctly.
    - cryptonector 7y ago
      But you also have to test the whole system.
      - penagwin 7y ago
        For sure. There's dozens of types of tests (although many don't apply to certain use cases). In a healthy system you should be using a lot of them. And they don't stop at deployment, you need to be tracking exceptions (after all, production is the final, and best test environment). This article has some nice diagrams of the different kinds of tests https://medium.com/@copyconstruct/testing-in-production-the-safe-way-18ca102d0ef1 https://medium.com/@copyconstruct/testing-in-production-the-...

Armisael16 7y ago

That isn’t at all what happened.

VBprogrammer 7y ago

That's one reason I hate complexity in tests. Your tests have to be dumb enough that you are 99% sure the code under test is at fault.

WrtCdEvrydy 7y ago
By definition, tests have to be more complex than the underlying code. The test have to setup the conditions, execute the action and validate it. Don't confuse complexity with shitty unreliable tests (timing-based tests)
- penagwin 7y ago
  Depends on the type of test. What you guys are talking about are unit tests, and are designed to test individual methods/functions. You write a separate test for each one. There's other types of testing, integration tests sound like what you are both complaining about. Integration tests test the interaction between components of a system, and are thus far more complex and likely to break as you're developing (which is a huge pain). However integration tests have their place - just because the function works doesn't mean it's being called from the web client correctly.
  - cryptonector 7y ago
    But you also have to test the whole system.
    - penagwin 7y ago
      For sure. There's dozens of types of tests (although many don't apply to certain use cases). In a healthy system you should be using a lot of them. And they don't stop at deployment, you need to be tracking exceptions (after all, production is the final, and best test environment). This article has some nice diagrams of the different kinds of tests https://medium.com/@copyconstruct/testing-in-production-the-safe-way-18ca102d0ef1 https://medium.com/@copyconstruct/testing-in-production-the-...