According to git history I do ;)
Ask HN: Do you write tests before the implementation?
131–140 of 329 posts
Re: Ask HN: Do you write tests before the implementation?
#132If the problem is complex, or I don't well understand the requirements, I write tests first.
For complex tasks, breaking down the problem into a single requirement per test helps me understand it better, and ensure I don't introduce regressions while refactoring or adding new requirements.
However, a lot of modern code is hooking up certain libraries or doing common tasks that don't get a lot of value from unit tests (mapping big models to other models, defining ReST endpoints, etc), so I don't generally write unit tests for those (but integration)
Re: Ask HN: Do you write tests before the implementation?
#133Earlier quoted context omitted.
I see you're aiming for the sainthood too. You don't also happen to help elderly women across the road, let everyone else out at a junction and never fail to say 'please' and 'thank-you'?
At the risk of being serious for a moment, saying "please" and "thank you" are two of the lowest effort, highest reward, and plainly decent things you can do as a human.
Looks like we found the Canadian!
All jokes aside, yea... I mean... that's normally beaten into you as a child even if you grew up white trash. I would know.
Re: Ask HN: Do you write tests before the implementation?
#134I could write a test plan first, but I haven't always fully designed the interfaces until I've ploughed into the code and figured out what needs to be passed where, so there would be a lot of repeat effort in fixing up the tests afterwards.
Effectively, in writing tests first you make assumptions about the code. These don't always turn out to be true.
Re: Ask HN: Do you write tests before the implementation?
#135When I build a new web app, I start with a REST API. The input and output are known, so bugs are less likely. As I roll out new API methods, I add it to a postman collection, and add a couple of tests to it. Then with each deploy, I point my postman to that environment and hit run.
When building the client application, I typically just manually test as I go along. Bugs happen, but because the foundation code is all REST API, the bugs are usually and easily fixed.
Re: Ask HN: Do you write tests before the implementation?
#136I can't even code like that except maybe for simple tasks in a mature project. I'm more a "Make It Work, Make It Beautiful, Make It Fast" person and don't see it working by writing unit test first.
I think the value of TDD's red–green–refactor cycle is in making sure that after you "Make It Beautiful" it still works, and again after you "Make It Fast" it still works. Otherwise, if you don't automate the test first, you end up testing manually three times.
exactly, lots of people are missing the point.
Re: Ask HN: Do you write tests before the implementation?
#137No. 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 used to be a TDD zealot. In recent years, I've taken a much more selective approach to test coverage. I typically focus my testing on pieces of code that contain business logic whereas I used to test everything. I've also found automated UI testing is not worth the squeeze and I've had better luck just looking at impacted objects and manually testing those.
I'd be interested to hear if anyone has automated UI testing tools in place that are easier to write test cases for than to just do the manual testing.
Re: Ask HN: Do you write tests before the implementation?
#138No. 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…
This is a good point. Just like with anything in engineering understanding the process is more important than just following some steps because you think you should.
When developing software there are many steps before testing even occurs to catch problems, and the earlier you catch problems the better. Coding standards, having requirements, and peer reviews all are important too.
I find tests useful for having a "checklist" of things to do before releasing a new build. In robotics automated tests are especially helpful since there is a lot of code which only happens in certain physical conditions which are hard to recreate manually (i.e. in a low battery condition the robot should do this behavior). But just having the checklist is more important than how you execute it.
Re: Ask HN: Do you write tests before the implementation?
#139I am quite curious to know what percentage of working devs ever write tests at all. Because I don't think it's the majority, based on my own professional anecdata.
But I've not yet been convinced that any of the various polls are very authoritative. So I dunno.
Re: Ask HN: Do you write tests before the implementation?
#140No, my clients wouldn't work with me then...
On a serious note, I find it hard to write the tests at the beginning for a code that I'm not sure how/what is gonna do. What do I mean by that? Well, as all you probably have experienced, requirements change during development, sometimes 3rd party/microservices/db constraints don't let us achieve what we want. We have to come up with hacky/silly solutions that would require us to rewrite most of the tests that we wrote.
A lot of times I don't even know how to code the stuff I'm required to build. How am I supposed to write tests in that kind of situations? I think it would be like building abstractions for problems that I don't know very well yet.