4 ms·

I sitll don't understand whether TDD applies outside of some rather specific domains. In most cases, apart from utility methods, I don't actually know how some

I sitll don't understand whether TDD applies outside of some rather specific domains. In most cases, apart from utility methods, I don't actually know how something will work before I have at least partially implemented it. We have implemented a payments change recently (Paypal to Recurly) and not only are the two very different but we have added additional functionality that we could have done with Paypal but didn't. How do you TDD that? Even writing a simple test like "Go to this page and click <Order>" doesn't really work since when you come to it, you realise you can't just order but you also need to go to the create account page first etc.

projektfu 5y ago
A lot of effective functional testing is getting fixtures ready so that your test can reliably hit the important part of the system under test. For external integrations this becomes difficult. Presumably your test uses the api sandbox, so hopefully it gives reproducible results. If not, then you need to test manually and focus on unit testing to assure the software.
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.

projektfu 5y ago

A lot of effective functional testing is getting fixtures ready so that your test can reliably hit the important part of the system under test. For external integrations this becomes difficult. Presumably your test uses the api sandbox, so hopefully it gives reproducible results. If not, then you need to test manually and focus on unit testing to assure the software.

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.