3 ms·

I can answer - most of the time I do not know at start what data structure/effect should be the exact result of my code, even if it is just a more complicated v

by juskrey 10y ago

I can answer - most of the time I do not know at start what data structure/effect should be the exact result of my code, even if it is just a more complicated version of the "hello world".

heimidal 10y ago
In TDD, you write the test to help figure this out. The idea is that you start with "how do I call this method/interact with this code/etc?", then ask yourself, "what should the result be?" TDD is meant to help inform your design thinking, but there's no rule that says you can't change your mind as you go.
- AnimalMuppet 10y ago
  In particular, you should be changing your mind as a result of trying to write the tests. If it's hard to write a test, that's telling you something - the interface is clumsy to use, for example. TDD is different from just writing tests, because the tests drive development. "Drive" may be a bit too strong, but they at least significantly influence it.
ajmurmann 10y ago
In that case write higher level tests. TDD works best and provides most value when you go outside in. So your initial test would just determine that you expect to see "hello world" printed. Maybe on the next level down you now have to do some validation and you have to define how the interface (not used in the Java sense here) of the function or object or whatever looks that does the validation. The key thing here is that you don't need to think about how that will actually work on the inside, but how you want it to be exposed. As you start to TDD that portion of your code that implements that new functionality your tests shouldn't care too much about how the code under test is implemented, only about its outside behavior (this might include calls to other functions though that ideally get mocked). This process makes it easier to many practitioners to increment on functionality that they don't know in advance how to implement. That's why it's called "test driven development" and not"test first development". All that being said, determining the right amount and granularity of tests is certainly much more of an art than a science and friends on the developer(s), what the system is doing, framework and the language you are using. I definitely write many more tests when I'm writing Ruby code than when I'm writing Rust. I'm also very new to Rust so we will see if that lasts.
- steveklabnik 10y ago
  TDD is also a bit weird in Rust since you can't do nearly as much of the dynamic tricks test frameworks tend to do. So I find myself writing less tests for this reason, or at least, different kinds of tests.

by juskrey 10y ago

I can answer - most of the time I do not know at start what data structure/effect should be the exact result of my code, even if it is just a more complicated version of the "hello world".

heimidal 10y ago

In TDD, you write the test to help figure this out. The idea is that you start with "how do I call this method/interact with this code/etc?", then ask yourself, "what should the result be?" TDD is meant to help inform your design thinking, but there's no rule that says you can't change your mind as you go.

AnimalMuppet 10y ago
In particular, you should be changing your mind as a result of trying to write the tests. If it's hard to write a test, that's telling you something - the interface is clumsy to use, for example. TDD is different from just writing tests, because the tests drive development. "Drive" may be a bit too strong, but they at least significantly influence it.

ajmurmann 10y ago

In that case write higher level tests. TDD works best and provides most value when you go outside in. So your initial test would just determine that you expect to see "hello world" printed. Maybe on the next level down you now have to do some validation and you have to define how the interface (not used in the Java sense here) of the function or object or whatever looks that does the validation. The key thing here is that you don't need to think about how that will actually work on the inside, but how you want it to be exposed. As you start to TDD that portion of your code that implements that new functionality your tests shouldn't care too much about how the code under test is implemented, only about its outside behavior (this might include calls to other functions though that ideally get mocked). This process makes it easier to many practitioners to increment on functionality that they don't know in advance how to implement. That's why it's called "test driven development" and not"test first development". All that being said, determining the right amount and granularity of tests is certainly much more of an art than a science and friends on the developer(s), what the system is doing, framework and the language you are using. I definitely write many more tests when I'm writing Ruby code than when I'm writing Rust. I'm also very new to Rust so we will see if that lasts.

steveklabnik 10y ago
TDD is also a bit weird in Rust since you can't do nearly as much of the dynamic tricks test frameworks tend to do. So I find myself writing less tests for this reason, or at least, different kinds of tests.