231–240 of 329 posts
Yeah. I also floss every day, clean up the kitchen as I cook, keep off-site backups of my personal data, call my mother regularly to thank her for raising me, read the terms and conditions to online services, keep an up-to-date to-do list, and change all my passwords once a month.
Suddenly I feel very lonely for the fact I do actually clean the kitchen during and right after cooking...
No. Tests are like any other code. They incur technical debt and bugs at the same rate as other code. They also introduce friction to the development process. As your test suite grows, your dev process often begins to slow down unless you apply additional work to grease the wheels, which is yet another often unmeasured cost of testing in this fashion. So, in short, I view tests as a super useful, but over-applied too…
Maybe you can help me understand this. Since you don't write as many tests, that means you're not actually testing all your code branches because tests incur technical debt after all. So does this mean you test every single branch manually? just don't bother with it at all? Do you just have a few integration tests and they break and you spend a good chunk of time figuring out which logical branch broke? What happens…
I manually test my current branch manually while developing and do sanity checks when it's merged somewhere. I do write tests for some cases, but rarely, only to save time when I have to test against a wide range of input parameters.
Earlier quoted context omitted.
Enlighten me, why?
Not sure I'd call it a 'bad bad practice' for a user to do it voluntarily, but it's unnecessary. I think the above commenter is thinking about the requirement a user to change a password on a timed basis. There's been a good bit of research done in this area, and the consensus is that it just causes most people to stick a number at the end of their password anyway, making the policy completely worthless at best, but…
Yeah. I also floss every day, clean up the kitchen as I cook, keep off-site backups of my personal data, call my mother regularly to thank her for raising me, read the terms and conditions to online services, keep an up-to-date to-do list, and change all my passwords once a month.
Suddenly I feel very lonely for the fact I do actually clean the kitchen during and right after cooking...
Earlier quoted context omitted.
It's weird... I'm a real lazy person. I do the dishes immediately because of this reason, it's faster and easier. I absolutely hate doing crusty dishes. So, I'm just confused in general why people wait. Its straight up less effort to do it sooner than later.
Do you have kids? I always had the same opinion until I had my daughter, and then all of a sudden there is a 2 year old who needs supervision and it becomes easier to clean up after bed time.
No. Tests are like any other code. They incur technical debt and bugs at the same rate as other code. They also introduce friction to the development process. As your test suite grows, your dev process often begins to slow down unless you apply additional work to grease the wheels, which is yet another often unmeasured cost of testing in this fashion. So, in short, I view tests as a super useful, but over-applied too…
I take the perspective that tests - and particularly unit tests - are a living specification for the software that you know cannot be out of date. If you write tests in a way that you understand the business purpose of the system, you are providing a significant part of the documentation while also providing a regression suite that is automated. There are other ways to handle this. You can have a design document that…
No. Tests are like any other code. They incur technical debt and bugs at the same rate as other code. They also introduce friction to the development process. As your test suite grows, your dev process often begins to slow down unless you apply additional work to grease the wheels, which is yet another often unmeasured cost of testing in this fashion. So, in short, I view tests as a super useful, but over-applied too…
> The change curve says that as the project runs, it becomes exponentially more expensive to make changes.
> The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work.
> At the core are the practices of Testing, and Continuous Integration. Without the safety provided by testing the rest of XP would be impossible. Continuous Integration is necessary to keep the team in sync, so that you can make a change and not be worried about integrating it with other people.
> Refactoring also has a big effect
- Martin Fowler
If it's an application or framework, I usually drive it from the UI, so tests are more an afterthought or a way to check / ensure something.
I find the best balance is to have thick libraries and thin applications, but YMMV.
If I'm writing something where I know what the API to use it should be and the requirements are understood, yes, I'll start with tests first. This is often the case for things like utility classes: my motivation in writing the class is to scratch an itch of "wouldn't it be nice if I had X" while working on something unrelated. I know what X would look like in use because my ability to imagine and describe it is why I want it.
There are times, however, where I'm not quite sure what I want or how I want to do it, and I start by reading existing code (code that I'm either going to modify or integrate with) and if something jumps out at me as a plausible design I may jump in to evaluate how I'd feel about the approach first-hand.
I'm short, the more doubts or uncertainty I have about the approach to a problem (in the case of libraries, this means the API) the longer I'll defer writing tests.