My pairing partner and I was doing silent ping pong. Ping-pong style pair programming is when one programmer writes a test and passes the keyboard to the partner, who writes enough code to pass the test. He or she then writes a new test and passes control back to the first person. In the silent variety, you’re not allowed to talk.
Seriously?
I swear, the more I hear about “Agile”, the sillier it gets and the more I want to get out of this industry. All I know is that before “Agile” was being shoved down our throats by new management, my department never missed a deadline and only two bad deployments in a decade. Now? It’s been an unmitigated disaster and I’m surprised we even still have our customer (the Oligarchic Cell Phone Company).
Okay, rant over.
For testing, we basically give them a base name (for the overall feature) and a number. If a test fails, you can check the testcase itself to see how it should work, given that a testcase contains how the data should be configured and what is expected to be returned (I should note we’re using a custom testing tool because of the nature of our codebase).
Not only that, but once we’ve established that “silent ping pong” is a thing the author thinks is a good idea, why on earth would I continue reading anything else they’ve got to say about programming?
I happen to work on a codebase that uses pytrst marks for this, because slow tests get run less often and pytest marks are how the system knows which tests count as slow. In a different codebase this might not be relevant at all, or perhaps some other categorization scheme might make sense. This doesn’t affect the names of test functions at all.
We’ve split our naming by feature and camelcase and snakecase folder and file names respectively, for example, featureSuite/by_activity_feature_license.spec.js. Then the test name passed to the describe block uses the language filename variable: describe(__filename….
Then the it/test block contains the GIVEN WHEN THEN statement which is broken onto code flow comments on the test describing what the test logic is accomplishing.
This assists with identifying test domain and test flow. However it does not reduce required debugging knowledge. Our goal is to make the tests readable first then fast, focused which lends to simplicity and finally if required they can be clever (but cleverness will eventually harm simplicity).
The name is important when the test suite fails, because then it’ll show the names of the failing tests!
Seriously?
I swear, the more I hear about “Agile”, the sillier it gets and the more I want to get out of this industry. All I know is that before “Agile” was being shoved down our throats by new management, my department never missed a deadline and only two bad deployments in a decade. Now? It’s been an unmitigated disaster and I’m surprised we even still have our customer (the Oligarchic Cell Phone Company).
Okay, rant over.
For testing, we basically give them a base name (for the overall feature) and a number. If a test fails, you can check the testcase itself to see how it should work, given that a testcase contains how the data should be configured and what is expected to be returned (I should note we’re using a custom testing tool because of the nature of our codebase).
Not only that, but once we’ve established that “silent ping pong” is a thing the author thinks is a good idea, why on earth would I continue reading anything else they’ve got to say about programming?
It’s an exercise. Not a way to work. They even said as much in the article you are commenting on, but I guess you skipped that part?
tests should be named fast or slow, and maybe a bit of context.
I happen to work on a codebase that uses pytrst marks for this, because slow tests get run less often and pytest marks are how the system knows which tests count as slow. In a different codebase this might not be relevant at all, or perhaps some other categorization scheme might make sense. This doesn’t affect the names of test functions at all.
sounds like a good setup!
We’ve split our naming by feature and camelcase and snakecase folder and file names respectively, for example,
featureSuite/by_activity_feature_license.spec.js. Then the test name passed to thedescribeblock uses the language filename variable:describe(__filename….Then the
it/testblock contains the GIVEN WHEN THEN statement which is broken onto code flow comments on the test describing what the test logic is accomplishing.This assists with identifying test domain and test flow. However it does not reduce required debugging knowledge. Our goal is to make the tests readable first then fast, focused which lends to simplicity and finally if required they can be clever (but cleverness will eventually harm simplicity).