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