Gregory's Server@jjoelson But how do you know what types the model needs?
|
8 comments
 @jjoelson We write tests for end user outcomes. How do you know what types the model needs? @jasongorman By the same token, how do you write tests if there are no types defined anywhere? @jasongorman My original point is writing model types can sit alongside writing tests as an activity that clarifies what your system actually *is* and *does*. It sounds like you prefer to think in terms of *behaviors*, hence your focus on tests as the starting point. For me, modeling the problem data domain is a more helpful starting point because it’s difficult for me to think about overall system behaviors in such an abstract way without having types to organize and guide. @jasongorman This is interesting, because you seem to agree that writing the types and method signatures is a necessary prerequisite to writing complete tests, but of course if you stopped after writing the types and never actually finished the tests then you’ve already done a chunk of the thinking about the system’s behavior. My original point is that the more expressive the type system, the more you’ve achieved in terms of understanding what your code will do just by writing the types. @jjoelson In TDD, we work backwards from the test code. It tells us what types and methods we need, and we declare those types *only* when a failing test requires it. We don't write a single line of source code that isn't required for the test. The tests drive the design. The clue's in the name, really 🙂  @jasongorman @jjoelson |
@jasongorman This is like asking a TDD practitioner “how do you know what tests to write?” and the answer is the same.