3 ms·

Right, so in my model, there's four goals you might have for testing: understanding users, understanding runtime behavior (of your software), correct functional

Right, so in my model, there's four goals you might have for testing: understanding users, understanding runtime behavior (of your software), correct functionality, stable functionality. Which set you choose depends on business goals. In a startup environment your goal is often understanding users (does anyone care about this product/feature? is it usable?) followed by correctness. And as you say, stability isn't an immediate concern if you're rewriting everything every two weeks, which is the case for many layers of code. "I'd put it this way, the first order benefit of TDD is confidence that refactoring will pass fewer regressions to production." - I'd say automated tests, including unit tests and therefore TDD, only give you stable functionality. Not correctness, since only a human can determine that (see essay for fleshed out argument - https://codewithoutrules.com/2017/03/26/why-how-test-software/ https://codewithoutrules.com/2017/03/26/why-how-test-softwar..., section on "What means of testing can you use?"). But unit tests (and thus TDD) for code that isn't going to be a stable is actually a negative, because you're trying to enforce stability on something that keeps changing. -- Could you link to the Cooper/Markham discussion?

brudgers 10y ago
Cooper and Markham were at the top of the link in the question. {edit: I have been mistaking you for the OP sandGorgon} -- I can see how A/B testing might help with understanding users, but to me, A/B testing is orthogonal to Test Driven Development and early on A/B testing would probably not have enough test cases to generate deep statistically significant insights due to small sample sizes and the need to make gross movements rather than fine tuning a working process. -- For Uncle Bob, TDD is a business process because he is selling consulting at some hourly/weekly/monthly rate. His client base will tend to be looking at improving stable business processes not those taking a spin of startup roulette. For a technology startup, what gets developed in house will tend to be strategic in the sense that it has a big effect on the company's velocity. Getting 'there' in three months is more than eight times as good as getting there in two years.
- itamarst 10y ago
  Ah, thanks, will read through. A/B testing is orthogonal to TDD, yes, and that's really the point: there's many forms of testing (usability testing, testing user interest, as well as A/B testing) whose goal is completely different than verifying a specification. Often they are useful when creating the specification. And maintaining stable software is very different than spinning up new product, yes. So you need to start with business goals, work down to testing goals, and then choose testing techniques based on those.

brudgers 10y ago

Cooper and Markham were at the top of the link in the question. {edit: I have been mistaking you for the OP sandGorgon} -- I can see how A/B testing might help with understanding users, but to me, A/B testing is orthogonal to Test Driven Development and early on A/B testing would probably not have enough test cases to generate deep statistically significant insights due to small sample sizes and the need to make gross movements rather than fine tuning a working process. -- For Uncle Bob, TDD is a business process because he is selling consulting at some hourly/weekly/monthly rate. His client base will tend to be looking at improving stable business processes not those taking a spin of startup roulette. For a technology startup, what gets developed in house will tend to be strategic in the sense that it has a big effect on the company's velocity. Getting 'there' in three months is more than eight times as good as getting there in two years.

itamarst 10y ago
Ah, thanks, will read through. A/B testing is orthogonal to TDD, yes, and that's really the point: there's many forms of testing (usability testing, testing user interest, as well as A/B testing) whose goal is completely different than verifying a specification. Often they are useful when creating the specification. And maintaining stable software is very different than spinning up new product, yes. So you need to start with business goals, work down to testing goals, and then choose testing techniques based on those.