3 ms·

Like I said, tests are also subject to user error. I’ve seen scenarios where tests passed when they shouldn’t have because the test itself was wrong. Or situati

Like I said, tests are also subject to user error. I’ve seen scenarios where tests passed when they shouldn’t have because the test itself was wrong. Or situations when test coverage was good but a basic type check seemed so obvious it was forgotten to be added. Some of those tests wouldn’t even have been needed in Rust or Go. I do agree that tests are important; hence why I raised that point from the outset. But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. Which is the point I was raising. Go and Rust are better at catching stupid user error. Clearly though you can write large projects in Python if you’re disciplined enough. Same could be said for C, BBC BASIC or even assembly. The question isn’t whether you can, it’s whether other languages makes it easier or not.

pytester 8y ago
>But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. You don't though. The tests you'd write which would catch these "stupid user errors" are basic ones which you'd be remiss not to write in any language. The fact that frequently developers do choose not to write any tests at all on large code bases does mean that they start to rely heavily on compiler catching 'stupid user errors' but it doesn't have to be that way. >Go and Rust are better at catching stupid user error. ...if you don't have a basic level of tests, yes. (although rust does provide certain type level protection against, say, data race bugs which python doesn't).
- pushpop 8y ago
  You’re flip flopping all over the place with your descriptions of tests. Broadly speaking, There are two types of tests being discussed here. Those are positive tests and negative tests. Positive being that the code does what you expect under normal operation. Those you’d obviously need in any language Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. If your compiler flat out refuses to send a string type to a function that is designed to accept an integer then you’re already covering a whole class of bugs without needing to write specific tests for it.
  - pytester 8y ago
    >You’re flip flopping all over the place with your descriptions of tests. The straw man of my argument living in your head flip flopped. I did no such thing. When I said "basic tests" I meant demonstrate the behavior under normal circumstances". If you're doing TDD on 60% of your code base you'll write enough of these. >Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. This is a completely unsuitable use case for a test. If your function expects non-garbage it should raise an exception if it gets garbage with a sanity check. I wrote one just a few hours ago like so: assert no_nans(dataframe)
    - pushpop 8y ago
      I have no problems with exception per se but what you’ve now done is push your error checking into the runtime which means your application could crash at unexpected times. This might be fine for your typical use cases but it is a terrible way to go about building software if you’re writing headless services. The point of functional tests is they catch developer errors before your codebase hits production. Which you cannot guarantee if your error checking is only in the runtime. Disclaimer: I write services used by millions of people (literally) each day. Some of those services are written in Python.
      - pytester 8y ago
        >I have no problems with exception per se but what you’ve now done is push your error checking into the runtime which means your application could crash at unexpected times. In theory but in theory any application could crash at an unexpected time. In my experience on a half decent code base these sanity checks never trigger during production in normal code; they're designed to get triggered during tests. They're there to make it easy to track down the root cause of bugs. The times when they did get triggered on production code I did it intentionally as a way to debug a train-wreck of an application in production. >it is a terrible way to go about building software if you’re writing headless services. Disclaimer: I write services used by millions of people (literally) each day. It's worked fine for me. I've been doing this for 10 years - on many projects that have had millions of users. You're not special.

pytester 8y ago

>But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. You don't though. The tests you'd write which would catch these "stupid user errors" are basic ones which you'd be remiss not to write in any language. The fact that frequently developers do choose not to write any tests at all on large code bases does mean that they start to rely heavily on compiler catching 'stupid user errors' but it doesn't have to be that way. >Go and Rust are better at catching stupid user error. ...if you don't have a basic level of tests, yes. (although rust does provide certain type level protection against, say, data race bugs which python doesn't).

pushpop 8y ago
You’re flip flopping all over the place with your descriptions of tests. Broadly speaking, There are two types of tests being discussed here. Those are positive tests and negative tests. Positive being that the code does what you expect under normal operation. Those you’d obviously need in any language Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. If your compiler flat out refuses to send a string type to a function that is designed to accept an integer then you’re already covering a whole class of bugs without needing to write specific tests for it.
- pytester 8y ago
  >You’re flip flopping all over the place with your descriptions of tests. The straw man of my argument living in your head flip flopped. I did no such thing. When I said "basic tests" I meant demonstrate the behavior under normal circumstances". If you're doing TDD on 60% of your code base you'll write enough of these. >Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. This is a completely unsuitable use case for a test. If your function expects non-garbage it should raise an exception if it gets garbage with a sanity check. I wrote one just a few hours ago like so: assert no_nans(dataframe)
  - pushpop 8y ago
    I have no problems with exception per se but what you’ve now done is push your error checking into the runtime which means your application could crash at unexpected times. This might be fine for your typical use cases but it is a terrible way to go about building software if you’re writing headless services. The point of functional tests is they catch developer errors before your codebase hits production. Which you cannot guarantee if your error checking is only in the runtime. Disclaimer: I write services used by millions of people (literally) each day. Some of those services are written in Python.
    - pytester 8y ago
      >I have no problems with exception per se but what you’ve now done is push your error checking into the runtime which means your application could crash at unexpected times. In theory but in theory any application could crash at an unexpected time. In my experience on a half decent code base these sanity checks never trigger during production in normal code; they're designed to get triggered during tests. They're there to make it easy to track down the root cause of bugs. The times when they did get triggered on production code I did it intentionally as a way to debug a train-wreck of an application in production. >it is a terrible way to go about building software if you’re writing headless services. Disclaimer: I write services used by millions of people (literally) each day. It's worked fine for me. I've been doing this for 10 years - on many projects that have had millions of users. You're not special.