4 ms·

Nothing in this article makes sense to me. What is this, Hungarian notation for tests? What if a test is testing that something shouldn’t happen? Apostrophes a

Nothing in this article makes sense to me. What is this, Hungarian notation for tests? What if a test is testing that something shouldn’t happen? Apostrophes aren’t even legal function names in most languages. (/s) > If the only output of a failing test is just a binary value like “FAIL”, that test is only giving one bit of information to the developer. Well that aaaand > A good test framework will also print the test name and a call stack. Ok so more than one bit of information, it literally tells you the line number and filename of the failed test so you can go look at it. But yeah maybe bad developer didn’t put any comments in the test and the code isn’t obvious but sure they’re gonna name the test using a magic template. > For example, they could point out that “should replace children when updating instance” So in Go we would have: func TestShouldReplaceChildrenWhenUpdatingInstance(t *testing.T) { … } Argh this nonsense cargo culting just does my head in and I should go to sleep.

hedora 4y ago
You obviously are not familiar with the third circle of golang continuous integration hell that is ginkgo+gomega: https://onsi.github.io/ginkgo/#adding-specs-to-a-suite https://onsi.github.io/ginkgo/#adding-specs-to-a-suite It’s actually worse than that example suggests. Stuff like Expect(“type safety”).ShouldBe(GreaterThan(13)) throws runtime errors. The semantics of parallel test runs weren’t defined anywhere the last time I checked. Anyway, you’ll be thinking back fondly to the days of TestShouldReplaceChildrenWhenUpdatingInstance because now you need to write nested function calls like: Context(“instances”, func …) Describe(“that are being updated”, …) Expect(“should replace children”, …) And to invoke that from the command line, you need to write a regex against whatever undocumented and unprinted string it internally concatenates together to uniquely describe the test. Also, they dump color codes to stdout without checking that they are writing to a terminal, so there will be line noise all over whatever automated test logs you produce, or if you pipe stdout to a file.
- doctor_eval 4y ago
  Oh yeah I’ve seen stuff like that, but I just figure it will collapse under its own weight and die. Of course not without wasting tens of thousands of developer hours. But not my developer hours. It’s crazy isn’t it? People inventing a DSL to describe tests which you could just see by reading the friggin’ source code. It’s like ORMs for tests. Let’s create an abstraction (test DSL) over another abstraction (a friggin’ programming language) so now we have to understand two languages. So of course the solution is to write tests for the tests. Which will require coverage analysis. To make sure the devs take it seriously, I f the tests on the tests don’t get 100% test coverage of the tests then the dice rolling app won’t build. Because you can never be too sure.

hedora 4y ago

You obviously are not familiar with the third circle of golang continuous integration hell that is ginkgo+gomega: https://onsi.github.io/ginkgo/#adding-specs-to-a-suite https://onsi.github.io/ginkgo/#adding-specs-to-a-suite It’s actually worse than that example suggests. Stuff like Expect(“type safety”).ShouldBe(GreaterThan(13)) throws runtime errors. The semantics of parallel test runs weren’t defined anywhere the last time I checked. Anyway, you’ll be thinking back fondly to the days of TestShouldReplaceChildrenWhenUpdatingInstance because now you need to write nested function calls like: Context(“instances”, func …) Describe(“that are being updated”, …) Expect(“should replace children”, …) And to invoke that from the command line, you need to write a regex against whatever undocumented and unprinted string it internally concatenates together to uniquely describe the test. Also, they dump color codes to stdout without checking that they are writing to a terminal, so there will be line noise all over whatever automated test logs you produce, or if you pipe stdout to a file.

doctor_eval 4y ago
Oh yeah I’ve seen stuff like that, but I just figure it will collapse under its own weight and die. Of course not without wasting tens of thousands of developer hours. But not my developer hours. It’s crazy isn’t it? People inventing a DSL to describe tests which you could just see by reading the friggin’ source code. It’s like ORMs for tests. Let’s create an abstraction (test DSL) over another abstraction (a friggin’ programming language) so now we have to understand two languages. So of course the solution is to write tests for the tests. Which will require coverage analysis. To make sure the devs take it seriously, I f the tests on the tests don’t get 100% test coverage of the tests then the dice rolling app won’t build. Because you can never be too sure.