71–80 of 105 posts
https://github.com/rails/rails/issues/5744
That said, I generally agree with DHH that many developers write too many of the wrong kinds of tests and this can make products brittle.
I share his disdain for Cucumber and rspec. I prefer clarity over syntactic sugar and non-programmer readability.
This is why I left Microsoft. Automated testing was a separate discipline - meaning there were "dev devs" and "test devs". Automated tests were written based on what the "test devs" had time for, not on the need or usefulness of such tests for the actual code. I was hired as a "test dev" - I had no industry experience at the time and figured I would give it an unprejudiced try to see if I liked it. I quickly realized…
> We all realize there is no benefit in testing if you ignore failures rather than acting to fix the bugs, but in much the same way that doing nothing when tests fail has no benefit, doing nothing when tests pass also has no benefit - so tests which always pass are just as useless as failing tests you ignore, as are tests which only turn up corner-case bugs that you would have been comfortable with shipping.
On the contrary, my opinion is that we don't see this often enough. Our bug database shows the current list of defects, and there is very very very little data on what does work. What is test covering, and how many defects are they finding within that coverage?
If your bug trend is heading downward, is it because the test org is distracted by something, or because there are fewer bugs that they are encountering?
A thought that folks reading this post might have an opinion on: "Libraries should be mostly unit tested. Applications should be mostly (and lightly) integration tested. Naturally, some parts of a complex app will behave like a library..." Agree or disagree?
$container->build('app')->run;A thought that folks reading this post might have an opinion on: "Libraries should be mostly unit tested. Applications should be mostly (and lightly) integration tested. Naturally, some parts of a complex app will behave like a library..." Agree or disagree?
I completely agree with David's assertion that there is too little focus paid to how to test properly or what over-testing looks like. Here's a question to the HN community... For a library you write yourself to, say, access a Web service, how do you go about testing it? (For example, if you want to write tests against an Akismet gem) I tend to write both unit tests and integration tests for it. My unit tests mock ou…
1) Config, connections, or whatnot are one-time only. You're not going to screw up many times.
2) Not all WebServices have their own test-server so count yourself lucky if the ones you use have them :)
3) You're testing their code instead of yours if you have to make sure correct data etc comes back.
I usually only write unit-tests if they came back with bad data and we did not anticipate it (edge-case situation).
The phrase “Don’t test standard Active Record association” jumped out at me, since I’ve discovered a major bug in the most basic function of Active Record associations in 3.0.x. https://github.com/rails/rails/issues/5744 That said, I generally agree with DHH that many developers write too many of the wrong kinds of tests and this can make products brittle. I share his disdain for Cucumber and rspec. I prefer clarity…
Nice read. I'm no Rails dev, so I'm curious about this one point from DHH: > 6. Don't use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests (and send me a bottle of fairy dust if you're there!) I mostly do C#, and teams I've recently been on have found SpecFlow tests to be an excellent time saver in communicating requirements and acceptance test criteria with customers. Has Cucumber not b…
Personally, I don't like Cucumber because it attempts to bridge the worlds of development and business but ends up serving neither very well. Its syntax gives it the verbosity of English while removing none of the brittleness of the underlying code. A non-programmer editing tests would need to learn Ruby to deal with the leaks in the abstraction, while a coder is better off describing behavior directly in rspec or Ca…
Note, I'm not talking about your average "look, a fancy dropdown control on Github" type of project. I rather mean the "look, it's the entire software stack of a TV" or the "hey, this software computes taxes for all households in a country" type of thing.
The stakeholders in such domains typically know quite well what they want, in terms of their domain. The software people know how to turn that into working, maintainable and usable software. Getting the automated tests to also be the acceptance test spec saves a lot of double work, and, most importantly, a lot of human error (acceptance spec not matching acceptance test done, etc).
Don’t use Cucumber... Thank God someone with a bullhorn finally said this. I was beginning to think I was alone in my hatred of Cucumber. (And my love of Test:Unit/Minitest.)
Earlier quoted context omitted.
Strongly agree, but also I think that the interesting thing is why this might be so and what it tells us about application architecture. The basic thing about tests is that once you have them passing, they represent statements about constraints on the program. In other words, they express your opinion of things that should not change. Unit tests are a bet that certain aspects of the implementation will not change. In…
Unit testing didn't fully make sense to me until I played around with quickcheck (and eventually theorem proving in Coq). Unit tests vanish nicely to theorems and (empirical) proofs if your code expresses a succinct API. This is one end of the testing continuum. I use this sort of stuff extensively when doing mathematical computing and statistics because there's usually a clear mathematical boundary. Once you're insi…
If a random testing framework is available in your language they really should be integrated as they are able to come up with some pathological examples.