Only mock things that would be difficult to setup in a test, is my approach. Then also set up some other ci jobs for the difficult stuff when we have time.
So the worst of us developers out there write tons of tests? We wish. Who cares if it's 80% or 100%, i'd rather inherit a codebase with lots of test coverage than without.
Test coverage is a plus but not more important. We have an end to end test system that runs on each commit. What I am saying is perfect code, simply written is way way more important than complete coverage. Tests, on my experience, don't make code better written or more concise. Given a choice between coverage and good code I choose good code. In my experience time is always short so I choose the time on good code. In practice this is a compromise anywhere but the most cashed up companies.
If I am understanding correctly, he is saying that well-written code requires fewer tests in order to be fully tested. Fully tested is better than untested, assuming that code is fully tested, well written code will require fewer tests.
That is my understanding, as it is rather hard to extract a solid argument from his posts.
He specifies "any tests", as do several other anti-test posts in this discussion, though often someone will reply to them and assume, like you have done, that they have another complex set of automated tests that they're happy about, and they're only railing against some unspecified subset of automated tests. I'm not sure if that's being over-charitable or not.
Oh I completely agree, and would much rather be working on a codebase with too many unit tests than too few. I'm trying to come up with the most charitable explaining that I can.
And what about test coverage for the tests? You do realize that tests are also code, right? They have bugs, maintenance overhead, and all the other things code has.
The worst code bases I've seen have more test code than code being tested. People try to write tests to cover every condition or input and in systems of even modest complexity that isn't possible, or at least not feasible in a finite time.
The actual code is the check on the tests. They cover each other, acting as though they are and there is some infinite recursion dishonest.
Tests do have a maintenance cost, but it is much lower than the maintenance cost of code without tests. Without manual tests if there a bug it must be caught manually, this costs human time every time the tests are run. That also presumes the humans do the tests correctly, have a new team, QA person out sick, what is the cost now?
The cost of not having tests is bugs in production. If I write code and there a bug that impacts production many millions of dollars are on the line, and this is true for many developers. Write software for any airplane? Crashes can causes crashes so they are dangerous and expensive. How about something more common, Write software software for an online store? If the shopping cart drops 1 in 1000 items that is a huge amount of money, not just because of lost sales, but also angry customers. You will want to run the tests at least a few thousands times to catch that, a human won't do this, an automated unit test suite is shell script and VM away from doing that.
Automated tests don't make this impossible but it reduces the amount of bugs that can make it through. If a test costs 10 hours of developer time at $500/hour and stop one bug that would have alienated 1% of customers. Then there would only need to be 500,000 customers worth $1 each. Clearly these numbers have insanely inflated costs, yet they still make sense for many businesses. And this is only accounting for one bug. Finding that bug did not consume the test, it is still ready for more. A good test can many bugs and last many years.
I don't disagree that tests are good and necessary. I take issue with the view that tests are somehow free, that more testing is better, or that tests are of such marginal cost that more effort developing tests than the product is considered a reasonable use of resources.
Also, the notion that "they test each other" is likely to be dangerous.
> Also, the notion that "they test each other" is likely to be dangerous.
About as dangerous as double entry bookkeeping. Of course it doesn't provide any absolute guarantees, but having people state things in multiple contexts and checking their consistency is one of the better approaches we have for finding errors.
Zipcar, the world’s largest car-sharing company, is looking to add new senior talent to our Engineering team.
Today, Zipcar provides hundreds of thousands of people with a viable alternative to traditional car ownership, saving them money, time and headaches. Around the world—from coast to coast, across Canada, the UK, and college campuses in between—people are making the decision to live car free and enjoying the convenience and environmental benefits of having “wheels when you want them”.
We’re working to transform Zipcar from its ‘startup roots’ into ‘a world-class engineering organization’. We're building a global platform to take the car-sharing and Zipcar experience all over the world.
The technology choices we’re standardizing on are:
Native Mobile applications on Android and iOS. Our goal is to launch new functionality on ‘mobile first’ wherever it makes sense.
Big Data technologies like Hadoop, Cassandra, Apache Spark, Clojure, Haskel, machine learning, etc are going to be core to what we do.
All back-end services are going to be written in Ruby, Scala or Java. Mobile apps are all native.
Responsibilities:
Senior member of an agile team focused on delivering components of the next generation Zipcar technology platform.
Work to achieve engineering quality standards that our members will love and that you and your team will be proud of.
Responsible for the delivery a series of small, discrete applications leveraging Ruby, Java and/or Scala in a fast-paced, team-focused environment
Lead the development of applications leveraging traditional and non-traditional data stores, such as Hadoop, Cassandra and others.
Zipcar is hiring software engineers! Help improve car sharing and bring Zipcar to new markets. Ruby/Rails/Scala, Backbone/RequireJS/Bower/Grunt/Gulp/Hadoop.
Make products that your friends and family will use.
Zipcar is hiring software engineers! Help improve car sharing and bring Zipcar to new markets.
Ruby/Rails, Backbone/RequireJS/Bower/Grunt/Gulp. Make products that your friends and family will use.
https://www.zipcar.com/
Software engineer: http://jobvite.com/m?3W4RAgwc Senior software engineer: http://jobvite.com/m?3t5RAgwK
"With grid forms, lengthy forms can easily fit above the fold. Which means less scrolling. "
Seems like a bad idea to me whenever designs attempt to "Fit stuff above the fold". Scrolling is a lot better, and I think it's better to present users with a portion of the information at a time and allow them to progress through a long form in a linear fashion. Vertical scrolling > horizontal progression.
