I write tests whenever something breaks. That way I have a record of what has broken in the past and nothing breaks twice.
Don't tell anyone.
Ask HN: Do you write tests before the implementation?
301–310 of 329 posts
Re: Ask HN: Do you write tests before the implementation?
#302Manual tests, yes. More in the lines of "user should be able to do this".
The developer does a round of these tests as best they can. Then they toss it to QA who tries to break it, but must also do the same tests.
It prevents a lot of bad design bugs, but adds almost no overhead.
Automated testing should be applied only where this manual testing becomes tedious or where we often make mistakes in testing.
Re: Ask HN: Do you write tests before the implementation?
#303Earlier quoted context omitted.
That is how I used to work; then I got into finance and there are two things different with the work I did before that (web/desktop/app (or too long ago; there was no 'testing' in the 80s) the software I write now has to be certified/audited to some extent and I cannot change/repair production software on the fly. That could costs a lot of money for certain bugs. So now I tend to write tests for everything and that h…
>So now I tend to write tests for everything and that helps a lot. Isn't that a separate issue from writing the tests before the implementation?
Yes, and I do both.
Re: Ask HN: Do you write tests before the implementation?
#304Earlier quoted context omitted.
Don't you think that if tests are effective, they may let you go faster? To put it another way, it is not surprising that error rates are similar since, presumably, you keep coding till you produce an error, fix it and then repeat. The question is how much error free code you wrote between the errors. If testing -- or any technique for that matter, like relaxing, jogging, discussing, planning -- reduces errors, it wi…
"Effective tests" are a bit like the sufficiently smart compiler, or No true Scotsman fallacy. Tests either take a long time to run because they're integration tests in disguise, or they mock and stub module boundaries and are an impediment to design refactoring because lots of tests are invalidated. I tend towards favouring unit tests for leaf modules, especially those that get reused a lot, and fewer but rich (and…
Depending on your use of the term "unit" and "integration" (testing taxonomy is bad), I tend to do the opposite, but with the addition of acceptance (user feature testing) to tie the whole thing together.
By this I mean that I unit test (as driven out by Discovery Testing i.e mocking collaborators) down the dependency graph until I hit a leaf node, which I will integration test against real external systems or black box unit test if the logic is self contained.
This sort of drives out a world where slow tests are kept to the leaf components, or the e2e acceptance, and everything else is quick with confidence in all the paths.
It certainly does lead to a world where refactoring is more costly because of the burden of these mocks but this isn't trying to follow Chicago TDD where the refactor step is part of the cycle, instead looking like London TDD where the testing puts pressure on the design itself, so refactors are far less common.
Re: Ask HN: Do you write tests before the implementation?
#305Earlier quoted context omitted.
So say you were writing a sorting algorithm and with unit tests (perhaps with TDD) you wrote tests like: - sort([]) should produce [] - sort([1]) should produce [1] - sort([1,3,2]) should produce [1,2,3] - sort([1,5,6,2,3,4]) should produce [1,2,3,4,5,6] You would test a few values and edge cases until you were confident it works for all lists. However, you can't be 100% sure that there's some list out there like [5,…
Isn’t this formal verification more for algorithms than implementations? Eg if I have to use Coq to prove my code works, what use is that for my C application? Porting the code to Coq seems to defeat the point of formal verification, I can much better use some property based testing method.
There's lots of options. You can write an implementation in Coq (it has its own functional language you code in), prove it correct in Coq and then "extract" (like transpiling) it to another language like OCaml for executing. There's ways to map C code into Coq to prove it's correct as well. All of this is machine checked. See the sel4 kernel to get more of a feel for it.
Property based testing sits somewhere between regular software testing with unit tests and theorem proving on the spectrum. It's much less time intensive to do but much less rigorous.
My point isn't that formal verification is better than everything. It has its trade-offs, just like TDD.
Re: Ask HN: Do you write tests before the implementation?
#306No.
Every time I try, I quickly fall out of the habit.
I do write high-level first and then implement code after establishing API/what I need these days (I end up re-writing that a few times) which seems ideal for TDD but just doesn't seem to work that way.
What I do do is add a unit test for (almost) every formal bug I come across, (to prove the bug, and fix it) so that but never happens again. Which over the years seems to have given the best results for backwards compatibility, stability etc
Re: Ask HN: Do you write tests before the implementation?
#307No. 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…
> Anecdotally, I've worked for companies that test super heavily, and I've worked for companies that had no automated tests at all. How did refactoring work at that latter company?
Those companies were mostly C#, with a bit of Ruby and JavaScript. The C# type checker generally made refactoring a non issue. In the case of JavaScript and Ruby, it was not much harder. Mostly find and replace. Sometimes a bit more work, depending on the complexity of the change. In general, the code bases were pretty well designed and modular enough that refactoring was pretty simple.
I tend to be a repl-driven developer, and I also use the product as I code. If you've ever watched Jonathan Blow programming on YouTube, that's similar to my process.
I find the majority of issues as I go. The bugs that slip through tend to be the surprising edge cases where I think I'm just modifying a single vertical, but there's some bleeding over into other verticals which I'm not using while developing. These sorts of bugs can usually caught by a handful of basic integration tests.
Re: Ask HN: Do you write tests before the implementation?
#308Earlier quoted context omitted.
I accept the reality of global warming (I'm almost a single-issue voter on the subject), but I look at it from a Bayesian point of view: if we compared two universes, one where AGW was real, and one where the scientific consensus was mistaken (not exactly unprecedented), popular opinion would probably vary by no more than 1% between the two. Humans tend to start with moral intuitions and tribal affiliations, and then…
Have you ever wondered why it became partisan to begin with? Lots of other issues are not partisan like "smoking causes cancer", everyone generally agrees that it does, even many years ago before the "science proved it". There is some science that is so obviously manipulated by power and money everyone knows something is wrong, but can't do anything about it.
I believe in this case the partisanship comes from less from the topic itself, but if you look into the proposed solutions, they all tend to shift money and power in a single direction and don't have much to offer in regards of actually changing the climate.
Re: Ask HN: Do you write tests before the implementation?
#309Earlier quoted context omitted.
tests can be used to clarify your intentions and what you are attempting to build. It's best place when you are actually starting from a clean slate. Just write enough code to make the test pass, no more no less. Refactor and repeat. In recent years I've never written any new piece of code without test first and can not be any happier. Beside the confidence a test gives you, it really a great way to pin down your tho…
Yeah... I have read that and told that to others many times. But the thing is some of my best work (rare, though) has not been to spec. To any spec. More like, when you are doodling on a paper. "This might be a lake with a duck. Nope scratch that, it's actually a dragon and those are its scales. Yep."
Yes, I understand what you mean. When I face uncertainty, I explore with not so much emphasis on testing. But once I am over with that exploratory phase, I funnel the learning into the TDD process to solidify my implementation and guide my design.
BTW, I rarely work from a well-defined spec these days.
Re: Ask HN: Do you write tests before the implementation?
#310I do, TDD gives me such a sense of confidence that now that I'm used to, it's hard not to use. > Can you describe the practical benefit? Confidence that the code I'm writing does what it's supposed to. With the added benefit that I can easily add more tests if I'm not confident about some behaviors of the feature or easily add a test when a bug shows up. > Do you happen to rewrite the tests completely while doing the…
> Confidence that the code I'm writing does what it's supposed to. With the added benefit that I can easily add more tests if I'm not confident about some behaviors of the feature or easily add a test when a bug shows up. Isn't this just the benefit of tests, not necessarily TDD?
Yes, it's a welcomed side effect of TDD'ing, TDD is more of a design tool. But also I have experimented with writing tests before/after the implementation. Code with tests written first seemed to always be just to the point and get one in the mindset of thinking ahead of your edge cases and pin them down