101–110 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.
Almost never. I’m roughing things out first, or iterating the APIs. When the functions, data and interactions seem to stabilize, then I’ll start to put tests in. Once, I started with tests, but I had to rip up a lot along the way. It is helpful to ensure testability early on. It might be easier for some devs to figure it out by actually coding up some tests early. I won’t argue against anyone who is actually producti…
I have a similar experience, but now I am forced to use Ginkgo, and the tool doesn't make sense without TDD and BDD - behavior driven development, so some people must be using it.
Nope. I pretty much always find it to be counterproductive. Most of programming happens in the exploration phase. That's the real problem solving. You're just trying things and seeing if some api gives you what you want or works as you might expect. You have no idea which functions to call or what classes to use, etc. If you write the tests before you do the exploration, you're saying you know what you're going to fi…
Hey here's a new concept for you "mocking". Learn to test this thread is pathetic man!
If I'm working with well-known tools and a problem I understand reasonably well, I'll approach it in ultra-strict test-first style, where my "red" is, "code won't compile because I haven't even defined the thing I'm trying to test yet". It might sound a step too far but I find starting by thinking about how consumers will call and interact with this thing results in code that's easier to integrate.
However, if I'm using tools I don't know well, or a problem I'm not sure about, I much prefer the "iterate and stabilise" approach. For me this involves diving in, writing something scrappy to figure out how things work, deciding what I don't like about what I did, then starting again 2 or 3 times until I feel like I understand the tools and the problem. The first version will often be a mess of printf debugging and hard-coded everything, but after a couple of iterations I'm usually getting to a clean and testable core approach. At that point I'll get a sensible set of tests together for what I've created and flip back to the first mode.
Earlier quoted context omitted.
Unit tests actually are the most important ones... I do not wanna work on any of your projects heh.
To each their own. I have seen many times all the unit tests pass, but the application is broken. It really depends on the situation. There is no silver bullet when it comes to testing.
I usually finish by checking the test coverage and trying to make it reach 100% branch coverage if I have the time. The coverage part is important because it usually makes me realize things could be made simpler, with fever if/else cases.
I could never get used to writing only the tests first simply because all the compilation errors get in the way (because the module doesn't exist yet).
But for code that’s trivial to implement, it seems unnecessary...
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.
Earlier quoted context omitted.
Do you consider coverage an effective metric? I've got some code that has a test suite which is effectively a bunch of low level driver checks, plus a bunch of common example snippets and checks for eg empty inputs etc. Coverage gives an idea of how many lines of code have been run, but obviously no guarantees of correctness for those specific lines (eg you can't detect a double negative). It's worked well for me so…
I would agree that "coverage gives an idea of how many lines of code have been run, but obviously no guarantees of correctness for those specific lines"
Coverage for example is a weak signal that you've at least run some fraction of your codebase at test time.