3 ms·

We added test suites after we were making money / people had to rely on our software. I think doing it before is kind of a waste of time... because who cares ab

by randall 13y ago

We added test suites after we were making money / people had to rely on our software. I think doing it before is kind of a waste of time... because who cares about well tested unused software. I'd say add them in after you have enough to pay one person full-time.

mkilling 13y ago
I agree with randall. Tests ensure that you build your software right, as opposed to building the right software. A large test suite impedes how fast you can deliver new features. We wrote tests for PlaytestCloud only after we acquired the first paying customers. The tests only ensured that customer-facing routes would not crash. It was a good balance to ensure that we could move quickly while ensuring that we didn't introduce catastrophic bugs.
conorgil145 13y ago
Putting off testing until you show traction can be a slippery slope. Writing tests early on can have many benefits including: better architecture/design, confidence the code performs as expected, regression testing when adding new features, ability to more quickly add new features because of the good design, etc. If the person in charge is the stereotypical "business type", then it can be difficult/impossible to convince him/her to allow engineers to spend time doing a refactor and/or writing tests for code which was written months ago and is "working fine" because you now are showing some traction. This can easily lead to never actually getting around to writing that robust and practical test suite that is really necessary in the long term. Note that I also say the test suite should be practical (for some definition of practical which may vary from engineer to engineer). For example, 100% test coverage may not be useful, determine which parts of the code MUST be tested and which parts are just diminishing returns, etc, etc.
- subsection1h 13y ago
  > If the person in charge is the stereotypical "business type", then it can be difficult/impossible to convince him/her to allow engineers to spend time doing a refactor and/or writing tests for code which was written months ago and is "working fine" because you now are showing some traction. What I've done on a couple of occasions was to tell the nontechnical stakeholders that automated tests must be added before the web app framework (or whatever significant dependency) could be upgraded. In the context of such an upgrade, they could understand the benefit of a test suite, and they signed off on it.
troels 13y ago
I have to agree with that. Tests are an investment in QA. Prioritising that before you have a product-market-fit is probably the wrong priority (Of course, depending on the specific scenario). A lot of thought leaders have been promoting testing like crazy the last couple of years, with the result that some people treat it like it's essential, when it rarely is.
ma2rten 13y ago
It depends. There are 4 situations I can think of where writing tests is essential: - mission critical code - before refactoring - people working on a codebase they don't understand completely (changing X might break Y) - implementing complicated algorithms In other situations, it's a almost a matter of taste: There are people who claim that writing tests will actually make you develop faster because you'll spend less time debugging. Also writing unit tests sometimes can make you think more systematic about all the edge cases an api needs to support.

by randall 13y ago

mkilling 13y ago

I agree with randall. Tests ensure that you build your software right, as opposed to building the right software. A large test suite impedes how fast you can deliver new features. We wrote tests for PlaytestCloud only after we acquired the first paying customers. The tests only ensured that customer-facing routes would not crash. It was a good balance to ensure that we could move quickly while ensuring that we didn't introduce catastrophic bugs.

conorgil145 13y ago

Putting off testing until you show traction can be a slippery slope. Writing tests early on can have many benefits including: better architecture/design, confidence the code performs as expected, regression testing when adding new features, ability to more quickly add new features because of the good design, etc. If the person in charge is the stereotypical "business type", then it can be difficult/impossible to convince him/her to allow engineers to spend time doing a refactor and/or writing tests for code which was written months ago and is "working fine" because you now are showing some traction. This can easily lead to never actually getting around to writing that robust and practical test suite that is really necessary in the long term. Note that I also say the test suite should be practical (for some definition of practical which may vary from engineer to engineer). For example, 100% test coverage may not be useful, determine which parts of the code MUST be tested and which parts are just diminishing returns, etc, etc.

subsection1h 13y ago
> If the person in charge is the stereotypical "business type", then it can be difficult/impossible to convince him/her to allow engineers to spend time doing a refactor and/or writing tests for code which was written months ago and is "working fine" because you now are showing some traction. What I've done on a couple of occasions was to tell the nontechnical stakeholders that automated tests must be added before the web app framework (or whatever significant dependency) could be upgraded. In the context of such an upgrade, they could understand the benefit of a test suite, and they signed off on it.

troels 13y ago

I have to agree with that. Tests are an investment in QA. Prioritising that before you have a product-market-fit is probably the wrong priority (Of course, depending on the specific scenario). A lot of thought leaders have been promoting testing like crazy the last couple of years, with the result that some people treat it like it's essential, when it rarely is.

ma2rten 13y ago

It depends. There are 4 situations I can think of where writing tests is essential: - mission critical code - before refactoring - people working on a codebase they don't understand completely (changing X might break Y) - implementing complicated algorithms In other situations, it's a almost a matter of taste: There are people who claim that writing tests will actually make you develop faster because you'll spend less time debugging. Also writing unit tests sometimes can make you think more systematic about all the edge cases an api needs to support.