4 ms·

I run into the problems with date-bound data all the time. It took me awhile of doing it the hard way. Now, if I'm working with dates, I usually always have a

by ap22213 13y ago

I run into the problems with date-bound data all the time. It took me awhile of doing it the hard way. Now, if I'm working with dates, I usually always have a 'DateCalculator' factory that injects dates into my domain objects. Now, it's easy to handle dates in my tests: just implement a DateCalculator as a mock. But, as for TDD, I think people can go way, way overboard. There are serious diminishing returns to doing TDD 'the right way'. I'm quite satisfied using unit tests to test particularly complex business logic / domain logic and as integration tests. I find that all too often devs will get so enamored with their 100s of tests that basically test nothing (as a ratio of functionality to lines of code), that they'll forget the main goal: shipping relatively high-quality software. Disclaimer: I started as a hack, worked for many years to become a non-hack, then devolved to a hack with caveats. Now, for me, it's all about achieving the right balance between speed and perfection. YMMV. Edit: shipping [relatively high-quality] software

araes 13y ago
"the main goal: shipping software." There is a point, where people seem to forget that unit tests are a tool that have a place, and should be used appropriately. There is a point where it becomes more like a bureaucracy, or buying into a religion, where its not about using the tests to solve problems, but about checking boxes or doing it the "right" way. I like tests. When a section of code is complex, and can't reasonably be refactored, a test is a good way to help build confidence that you've driven the wonkiness out of it, and don't reintroduce it with further changes. They help you catch dumb mistakes, where you change how you're passing a reference, or the type of child object a function sees, and suddenly, you're getting subtly wrong output. I do a lot of Computational Fluid Mechanics (CFD), and we've got a standard suite we run when we compile to make sure new changes haven't broken our base functionality. Still, in most cases, I'd much rather look for a refactoring or functionality combination option. I'd rather each piece be small enough that I can hold a mental model of it in my head, and not be too scared I'm missing something. However, also still a bit of a hack.
npinguy 13y ago
You've fallen into a common trap. A trap that many developers and managers do - that software is the goal. It's not. Software is a means to an end. A tool we built for users and customers to solve their problems. Software that doesn't solve the customer's problems might as well be gravel on a beach. Software that is shipped, but isn't maintained, will diverge from customer's needs as they change. And will become just as useless. So are you trying to precisely understand a customer's key requirements? Then you best represent them in unit tests. Are you building and releasing iteratively and getting customer feedback to make sure that customers are getting what they actually need? (A lot of times what people say they need changes once they actually get what they ask for) Then you need to be able to refactor frequently and fearlessly, and you best have tests. Are you considering future releases after shipping major versions? Same, you will need to refactor, and you will break existing functionality, and you need tests. I understand you want to be pragmatic. But don't think that the people that preach TDD are just sitting there in love with their best practices for their own sake. We have just been burned too many times and believe the best process and framework for delivering customer value via software is to build on a solid foundation.
- ap22213 13y ago
  EDIT: On second thought, I think it's an interesting topic of conversation. When I'm working, my primary goal is to make money. And, when I'm working for a client or boss or customer, that means being responsive and showing them value for _their_ money. Oftentimes, this means trying to protect them from themselves, but, again, I want to get paid. So, eventually, despite all my arguments, it turns back to me shipping software. They want to 'see' something for my expensive invoice, subscription fee, or salary. The payer doesn't care about all that 'stuff' that I do that they can't 'see'. So, yes, you're right. I do sacrifice quality at times to ensure that I get paid. It's not intentional. No way. But, I am a biased participant in this debacle: I have a perverse incentive to ship non-perfect software. I don't intentionally try to do so, obviously. But, there is an equilibrium point where I stop arguing and see that I can fix it in v2. Now, on my personal projects, I actually take my time. I do things the right way, because I have time on my side. I'm my own boss. And, in those cases, I actually do write full sets of unit tests. Interesting for me to observe this in myself. Thanks. But, yes, when I'm working for someone, I have considerable pressure to break the rules. You're right - it is a trap.

by ap22213 13y ago

araes 13y ago

"the main goal: shipping software." There is a point, where people seem to forget that unit tests are a tool that have a place, and should be used appropriately. There is a point where it becomes more like a bureaucracy, or buying into a religion, where its not about using the tests to solve problems, but about checking boxes or doing it the "right" way. I like tests. When a section of code is complex, and can't reasonably be refactored, a test is a good way to help build confidence that you've driven the wonkiness out of it, and don't reintroduce it with further changes. They help you catch dumb mistakes, where you change how you're passing a reference, or the type of child object a function sees, and suddenly, you're getting subtly wrong output. I do a lot of Computational Fluid Mechanics (CFD), and we've got a standard suite we run when we compile to make sure new changes haven't broken our base functionality. Still, in most cases, I'd much rather look for a refactoring or functionality combination option. I'd rather each piece be small enough that I can hold a mental model of it in my head, and not be too scared I'm missing something. However, also still a bit of a hack.

npinguy 13y ago

You've fallen into a common trap. A trap that many developers and managers do - that software is the goal. It's not. Software is a means to an end. A tool we built for users and customers to solve their problems. Software that doesn't solve the customer's problems might as well be gravel on a beach. Software that is shipped, but isn't maintained, will diverge from customer's needs as they change. And will become just as useless. So are you trying to precisely understand a customer's key requirements? Then you best represent them in unit tests. Are you building and releasing iteratively and getting customer feedback to make sure that customers are getting what they actually need? (A lot of times what people say they need changes once they actually get what they ask for) Then you need to be able to refactor frequently and fearlessly, and you best have tests. Are you considering future releases after shipping major versions? Same, you will need to refactor, and you will break existing functionality, and you need tests. I understand you want to be pragmatic. But don't think that the people that preach TDD are just sitting there in love with their best practices for their own sake. We have just been burned too many times and believe the best process and framework for delivering customer value via software is to build on a solid foundation.

ap22213 13y ago
EDIT: On second thought, I think it's an interesting topic of conversation. When I'm working, my primary goal is to make money. And, when I'm working for a client or boss or customer, that means being responsive and showing them value for _their_ money. Oftentimes, this means trying to protect them from themselves, but, again, I want to get paid. So, eventually, despite all my arguments, it turns back to me shipping software. They want to 'see' something for my expensive invoice, subscription fee, or salary. The payer doesn't care about all that 'stuff' that I do that they can't 'see'. So, yes, you're right. I do sacrifice quality at times to ensure that I get paid. It's not intentional. No way. But, I am a biased participant in this debacle: I have a perverse incentive to ship non-perfect software. I don't intentionally try to do so, obviously. But, there is an equilibrium point where I stop arguing and see that I can fix it in v2. Now, on my personal projects, I actually take my time. I do things the right way, because I have time on my side. I'm my own boss. And, in those cases, I actually do write full sets of unit tests. Interesting for me to observe this in myself. Thanks. But, yes, when I'm working for someone, I have considerable pressure to break the rules. You're right - it is a trap.