3 ms·
Well, you write code for design flexibility. Testing just forces the issue and helps you explore possible design needs. For example, what if the database query
by humanrebar 9y ago
Well, you write code for design flexibility. Testing just forces the issue and helps you explore possible design needs. For example, what if the database query you're using isn't suitable any more? Instead of designing around a User table, you start passing around User records. Then your design is more future proof in case you start getting Users from a service or in-memory cache instead of a database.
> ...not code for your problems...
Right. It's not your problem now. It may be your (or your successors') problem in the future.
Is it always worth the effort? Nope. But experience, communication, and good teamwork will help with balancing short-term and long-term goals.
- discreteevent 9y agoThis is exactly the problem. In general you should not be writing code for design flexibility. Your code should contain the minimum number of abstractions to satisfy its requirements. If flexibility is a requirement right now then that's ok. Otherwise refactor in the flexibility later. But don't make the code flexible for the sake of tests. It vastly over-complicates it for no benefit. Instead write tests as close to the requirements level as possible (ideally most of your tests should be just below the ui)
- humanrebar 9y ago> Otherwise refactor in the flexibility later. I'm saying, with experience, teamwork, communication (including through tests), you'll know when this proposition makes sense or not. It's not universally true that "we'll worry about it later" make sense.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]