5 ms·

Arkency, a very well-known Ruby consulting company (at least in Europe), are the ones I've seen shout about this 'rule' the loudest: https://twitter.com/arkency

Arkency, a very well-known Ruby consulting company (at least in Europe), are the ones I've seen shout about this 'rule' the loudest: https://twitter.com/arkency/status/1254784379190038534 https://twitter.com/arkency/status/1254784379190038534

latchkey 4y ago
My time at Pivotal Labs was similar. "The tests are the documentation!"
- Yoric 4y ago
  I have worked with a few developers who shared this motto. I didn't agree with them. While it's anecdotal, my understanding is that we were simply working on very, very different codebases. I was refactoring multi-million lines C++ codebases, implementing concurrent algorithms in which dependencies cannot be expressed through language constructs and I had to make non-trivial choices to prioritize performance, or safety, or security at the expense of readability. On the other hand, these (few) developers were working on writing fresh code, with less footgunny languages, with simpler data and control dependencies and didn't need to make hard choices due to perf/safety/security.
  - twobitshifter 4y ago
    I’ve surprisingly heard it said on a c++ project.
    - Yoric 4y ago
      That's... surprising indeed! What kind of domain was it?
      - twobitshifter 4y ago
        Simulation
- vkou 4y ago
  Oh? Their tests have 100% coverage of every feature, and every meaningful, non-obvious interaction between features?
  - latchkey 4y ago
    Pretty much yes, look them up. They are huge on TDD and pair programming.
    - vkou 4y ago
      I'll believe it when I see their codebase. In my experience (10 years in test infra for ~50 to 300-dev products)[1], for any non-trivial product, there's always a colossal testing gap between what I would consider to be thorough coverage and actually attained coverage. The combinatoric complexity I alluded to is one of the reasons for it. And this is despite significant and on-going investments in test cases, test infra, integration testing infra, and good overall dev culture around quality. Also, pair programming has nothing to do with any of this. Mentioning it is like saying that their tests are better because they use IntelliJ instead of Eclipse. It's a very interesting fact, but irrelevant to this. [1] I will, however, point out, that there have been many times in my career that I have said 'This comment should be a test'. Tests are incredible. [2] But there is no circumstance where I would ever agree with a blanket policy of 'Every comment should be a test'. [2] It's entirely feasible, and highly desirable to get a small project to the point where just running the tests makes you feel 100% confident in the correctness of your changes. It is highly desirable to drive large products towards such a point, but those efforts can, at best, approach it asymptotically, and cover some enumerated, but limited set of use-cases and data-flows. [3] [3] And don't even get me started on verifying adherence to security best-practices through testing. It's an utter miracle that security gets two thoughts from a test-writer, and those thoughts are inevitably "These checks are annoying, how do I disable them to get my test to work?"
      - latchkey 4y ago
        Wow, sounds like you’ve consistently worked only in some really shitty environments, sorry for you. The worst companies I've ever worked for, had no testing. Seriously, PL is all about TDD, I'm not joking. PP actually does matter because two people sign off on commits that they worked on together and it is quite an achievement to convince your coworker that you're sitting next to, to not write a test. Consider it a sort of checks and balances. PL's version of pair programming is 100% of the time, it works. I have been running an open source project for a few years now with 40k downloads a month on NPM. This project has a heavy dependency on two other projects. Testing isn’t 100%, but it is enough to rely on it for releases. I also started out with TDD as well. Nothing is perfect, in fact we just had a release yesterday with a contributed fix in it, that came with a test, and still ended up with a bug... but out of 118 tags, a few here and there isn't bad. I routinely upgrade all the dependencies and never hear a peep out of people who depend on it. Most recently, I wrote some software that ran on 20k servers... it was extremely well tested because if it failed, it could have caused massive amounts of downtime. I've worked for a number of other companies where we had fantastic testing infrastructure, CI/CD... mostly because we started from day one with that. Bolting it on after the fact, never happens to the degree it should. I just saw Hashicorp release Hermes today... and was saddened to see it had zero testing in it. I just sighed and closed the browser window. It just isn't worth it.
hbrn 4y ago
> assumptions - we’re a small, cohesive team of experienced & responsible engineers I found that pretty much any methodology works fine in a team like that. "Don’t comment the code" still sounds pretty crazy to me, but I can believe that it works for them.

latchkey 4y ago

My time at Pivotal Labs was similar. "The tests are the documentation!"

Yoric 4y ago
I have worked with a few developers who shared this motto. I didn't agree with them. While it's anecdotal, my understanding is that we were simply working on very, very different codebases. I was refactoring multi-million lines C++ codebases, implementing concurrent algorithms in which dependencies cannot be expressed through language constructs and I had to make non-trivial choices to prioritize performance, or safety, or security at the expense of readability. On the other hand, these (few) developers were working on writing fresh code, with less footgunny languages, with simpler data and control dependencies and didn't need to make hard choices due to perf/safety/security.
- twobitshifter 4y ago
  I’ve surprisingly heard it said on a c++ project.
  - Yoric 4y ago
    That's... surprising indeed! What kind of domain was it?
    - twobitshifter 4y ago
      Simulation
vkou 4y ago
Oh? Their tests have 100% coverage of every feature, and every meaningful, non-obvious interaction between features?
- latchkey 4y ago
  Pretty much yes, look them up. They are huge on TDD and pair programming.
  - vkou 4y ago
    I'll believe it when I see their codebase. In my experience (10 years in test infra for ~50 to 300-dev products)[1], for any non-trivial product, there's always a colossal testing gap between what I would consider to be thorough coverage and actually attained coverage. The combinatoric complexity I alluded to is one of the reasons for it. And this is despite significant and on-going investments in test cases, test infra, integration testing infra, and good overall dev culture around quality. Also, pair programming has nothing to do with any of this. Mentioning it is like saying that their tests are better because they use IntelliJ instead of Eclipse. It's a very interesting fact, but irrelevant to this. [1] I will, however, point out, that there have been many times in my career that I have said 'This comment should be a test'. Tests are incredible. [2] But there is no circumstance where I would ever agree with a blanket policy of 'Every comment should be a test'. [2] It's entirely feasible, and highly desirable to get a small project to the point where just running the tests makes you feel 100% confident in the correctness of your changes. It is highly desirable to drive large products towards such a point, but those efforts can, at best, approach it asymptotically, and cover some enumerated, but limited set of use-cases and data-flows. [3] [3] And don't even get me started on verifying adherence to security best-practices through testing. It's an utter miracle that security gets two thoughts from a test-writer, and those thoughts are inevitably "These checks are annoying, how do I disable them to get my test to work?"
    - latchkey 4y ago
      Wow, sounds like you’ve consistently worked only in some really shitty environments, sorry for you. The worst companies I've ever worked for, had no testing. Seriously, PL is all about TDD, I'm not joking. PP actually does matter because two people sign off on commits that they worked on together and it is quite an achievement to convince your coworker that you're sitting next to, to not write a test. Consider it a sort of checks and balances. PL's version of pair programming is 100% of the time, it works. I have been running an open source project for a few years now with 40k downloads a month on NPM. This project has a heavy dependency on two other projects. Testing isn’t 100%, but it is enough to rely on it for releases. I also started out with TDD as well. Nothing is perfect, in fact we just had a release yesterday with a contributed fix in it, that came with a test, and still ended up with a bug... but out of 118 tags, a few here and there isn't bad. I routinely upgrade all the dependencies and never hear a peep out of people who depend on it. Most recently, I wrote some software that ran on 20k servers... it was extremely well tested because if it failed, it could have caused massive amounts of downtime. I've worked for a number of other companies where we had fantastic testing infrastructure, CI/CD... mostly because we started from day one with that. Bolting it on after the fact, never happens to the degree it should. I just saw Hashicorp release Hermes today... and was saddened to see it had zero testing in it. I just sighed and closed the browser window. It just isn't worth it.

hbrn 4y ago

> assumptions - we’re a small, cohesive team of experienced & responsible engineers I found that pretty much any methodology works fine in a team like that. "Don’t comment the code" still sounds pretty crazy to me, but I can believe that it works for them.