4 ms·

> How do you TDD that? Counterquestion: how do you know, at each release, that the paypal-stuff still works? If the answer is "I test it by making a purchase

by berkes 5y ago

> How do you TDD that? Counterquestion: how do you know, at each release, that the paypal-stuff still works? If the answer is "I test it by making a purchase at each release", the obvious question is: why not automate this? That is one benefit of TDD. So why not start of with that automation? In your specific case, I would write a simple test first, that, says "on the page of the orange Y-combinator swag, order a shirt and receive a timely confirmation.". Which is subtly, yet importantly different from "go to X and click order". On the level of such acceptence tests, trying to keep away from implementation details like "pages", "buttons" and so on, helps with solving your problem too: you write down the intent&outcome, rather than the implementation. Focus on the business value. Solve that first. And fixate the outcome for all future: regardless of the PSP, pages, exact values (timely vs within 1 sec), actual confirmation-channels and whatnot, the business value is "green" when it works, and "red" when it doesn't. Then I start implementing it. Maybe just add one of these <iframe> things that Paypal offers, even. I don't really care: the quest thing to make it work. as long as it gets me to have that acceptance test green with least work, I'm happy. Happy, but certainly not done. Because the most overlooked part of TDD is the Refactoring. Red-Green-Refactor. Once it is green, start refactoring. Replace the iframe with some library. Go a step further and replace that with my own paypal-API-client. Connect that to my event-stream, or not.

gpderetta 5y ago
I think the parent was objecting to writing tests first, not to writing them at all. My experience is the same as the parent. Design, outside of a very rough and very high level upfront phase, is very much intertwined with the act of coding. This can be writing unit tests, but elevating them specifically to be the root of all design decisions is imho not necessary nor productive. Lately I have been writing a lot of python code (nothing fancy, mostly CRUD stuff) and I have been taking advantage of a persistently running python instance and sending code snippets to it as a quick way to explore the data and test code from my IDE. Doing the same via tests would both be slower and less productive as I would end up deleting 90% of them anyway.
- berkes 5y ago
  > I have been taking advantage of a persistently running python instance and sending code snippets to it as a quick way to explore the data and ... deleting 90% of them anyway How is that different from TDD other than the name "test" vs "snippet"? Tests are excellent tools to explore an API or a dataset. Tests are perfect for quick automation. And, most importantly: tests, like any code, should be constantly and consistently get refactored. So throwing 90% away is expected and perfectly fine. Just like I expect you'll write 110x as much production code than what ends in production in the end: it's quite common for me to write 200+ lines over hours, only to end up with a five-line diff in the final commit.
  - gpderetta 5y ago
    > How is that different from TDD other than the name "test" vs "snippet Lack of ceremony. Lack of assertions. No separate test cases. If any quick throwaway hacky code count as a test for the purposes of TDD, then sure, but it kind of waters down the meaning of tests.
    - berkes 5y ago
      > but it kind of waters down the meaning of tests. From the C2Wiki: > UnitTests are programs written to run in batches and test classes. Each typically sends a class a fixed message and verifies it returns the predicted answer. Which already is very "watery" afaik. And a snippet that verifies something does X, fits this perfectly. Your approach may "violate" many other testing- best-practices and even "rules", such as "tests should verify only one thing" or "each branch should have one test" or "tests may only go through public interfaces" and whatnot, but I consider it TDD, as long as the scripts and snippets are written before any code. And if written afterwards, it counts as automated testing, though with a broad definition of "automated, I guess.
      - gpderetta 5y ago
        Well, I expect the snippets to run and possibly uncover bugs, so the underlying code is already written (or is written at the same time). I run them manually but I keep a log and I periodically rerun them. So I guess it is not TDD but semi-automated testing (or better, an interactive way to end up with automated tests).

by berkes 5y ago

gpderetta 5y ago

I think the parent was objecting to writing tests first, not to writing them at all. My experience is the same as the parent. Design, outside of a very rough and very high level upfront phase, is very much intertwined with the act of coding. This can be writing unit tests, but elevating them specifically to be the root of all design decisions is imho not necessary nor productive. Lately I have been writing a lot of python code (nothing fancy, mostly CRUD stuff) and I have been taking advantage of a persistently running python instance and sending code snippets to it as a quick way to explore the data and test code from my IDE. Doing the same via tests would both be slower and less productive as I would end up deleting 90% of them anyway.

berkes 5y ago
> I have been taking advantage of a persistently running python instance and sending code snippets to it as a quick way to explore the data and ... deleting 90% of them anyway How is that different from TDD other than the name "test" vs "snippet"? Tests are excellent tools to explore an API or a dataset. Tests are perfect for quick automation. And, most importantly: tests, like any code, should be constantly and consistently get refactored. So throwing 90% away is expected and perfectly fine. Just like I expect you'll write 110x as much production code than what ends in production in the end: it's quite common for me to write 200+ lines over hours, only to end up with a five-line diff in the final commit.
- gpderetta 5y ago
  > How is that different from TDD other than the name "test" vs "snippet Lack of ceremony. Lack of assertions. No separate test cases. If any quick throwaway hacky code count as a test for the purposes of TDD, then sure, but it kind of waters down the meaning of tests.
  - berkes 5y ago
    > but it kind of waters down the meaning of tests. From the C2Wiki: > UnitTests are programs written to run in batches and test classes. Each typically sends a class a fixed message and verifies it returns the predicted answer. Which already is very "watery" afaik. And a snippet that verifies something does X, fits this perfectly. Your approach may "violate" many other testing- best-practices and even "rules", such as "tests should verify only one thing" or "each branch should have one test" or "tests may only go through public interfaces" and whatnot, but I consider it TDD, as long as the scripts and snippets are written before any code. And if written afterwards, it counts as automated testing, though with a broad definition of "automated, I guess.
    - gpderetta 5y ago
      Well, I expect the snippets to run and possibly uncover bugs, so the underlying code is already written (or is written at the same time). I run them manually but I keep a log and I periodically rerun them. So I guess it is not TDD but semi-automated testing (or better, an interactive way to end up with automated tests).