Hacker Newsnew | comments | show | ask | jobs | submit | darrencauthon's comments login

That's a neat tool you mention... is it available on Linux or OSX???? :P

-----


I should have figured you'd give me grief, darren. It has Linux and OSX support if you're willing to run windows in a VM ;)

-----


Yes, my gist, but also a Twitter conversation on how strong typing altered the need for tests. I've heard from a couple Haskell programmers about how the language practically eliminated the need for tests. I don't see how that's possible, but I also know Haskell.

I asked for a specific code example, and I threw out the scenario of a client who wants a contact us form that logs all responses and sends notification emails. I threw out a simple Ruby example where I tested the functionality, and I'm waiting to see the alternative.

-----


Haskell does not practically eliminate the need for tests. I am very concerned that Haskell programmers are getting the reputation for claiming such things because they're simply not true.

Haskell's type system does statically check many things you might want to write tests for which makes those particular tests unnecessary, but it doesn't eliminate the need for tests in general. If you hear any Haskell programmers making claims that sound like that please ask them to be more precise.

-----


Exactly! Even though haskell is pure, it's impure in the context of the complete system.

-----


Are you waiting to see the alternative, or waiting to be right?

The example given seems clear enough to extrapolate from.

-----


I'm waiting to see the alternative.

It's an honest question to ask in the face of an assertion about testing -- or how strong or static typing eliminates the need to verify that the code behaves as written. In the sample I provided, I provided a concrete example as to how I could verify that the code accomplishes the task. If tests are not needed, then fine... show me how with code that accomplishes the task and that show how.

Like the "unit" where the two operations are covered in one method... Sure, but how else would it be done? The client asked for the log and the email, so somehow, someway... someone has to write code to do it.

I threw up my Ruby sample in just a few minutes... why can't the alternative be coded up in a few more?

-----


How does what the OP posted not qualify as an alternative?

-----


You know, I've heard of Dash and my knee-jerk reaction has always been, "Eh, I'm ok lookin' stuff up."

But you know... maybe I'm not. I just installed it, and I'm going to give it a try.

-----


I couldn't finish it all - yet. It looks like this took a while, thanks for the attention!

-----


Does anyone know of a public example of a Rails application that does testing in the way that DHH says is good?

I'm tired of the talk talk talk talk talk talk of "proper" testing in Rails, yet the examples always seem to be hidden away behind company firewalls. I've only seen a couple Rails apps with Rails-Way test suites, and they were nightmares that took many minutes to run. But I have seen dozens of Rails apps written by opinionated Rails devs with strong views about what proper testing was... and the apps had no tests at all.

-----


If your tests take 10 seconds, how much did you really test?

The point it sounds like he's trying to make is that if you say things like "they were nightmares that too many minutes to run" you may be approaching testing from the wrong point of view. He sounds like he wants to say "let the tests take 5 minutes" and I agree with him, thats what CI is for. Commit your code, mark the issue your fixing, let CI tell you if its done or not, take your pomodoro break, coffee break, etc, then sit back down, and pick back up with your test results on the CI server and repeat the cycle, a 5 minute test suite is NOT A BAD THING...

If you think 5 minutes is terribly long spare a thought for us deployment engineers... my test suite involves building and tearing down entire VM's or PXE booted machines and depending on what software is being built and tested through deployment can take an hour or more.

-----


> If your tests take 10 seconds, how much did you really test?

I see your point, but time-to-test is a horrible proxy for quality of tests. Business logic isolated from external systems can run incredibly fast, so ten seconds worth of testing can mean an awful lot in that case. The nature of TDD basically demands that you structure your code that way to remain productive. Otherwise it's like using a text editor that takes five minutes every time you try to save a file.

That's my inherent frustration with this argument. Both sides aren't arguing for their methodologies, they're arguing against the byproducts of each others methodologies.

-----


Excluding the acceptance tests (written with capybara and spinach) the test suite for my current client takes less than three seconds on my machine, including the run time (excluding the phantomjs boot time) of the suite of ui-exercising JavaScript tests, and they are nearly comprehensive, testing every component contract from the client to the backend. The ATs run in a little under a minute, covering the major integration points. There is very little mocking in any of the suite, and no direct database access.

Testing hurts when you do it poorly or naively. I know because I've done it both ways, and when I find something harder than it ought to be I invariably find some point of coupling beneath the surface. When my design is good, my tests are fast and easy. If you listen to DHH you're going to have problems testing. Not because you have to when writing software, but because he's already made decisions for you which are bad or highly coupled. Don't fall for the straw man. There are better ways to do it.

-----


This article is hilarious. If you want to see why TDD, unit testing, isolation, etc. are important, a Rails app written the "Rails Way" is the first place you should look.

They all look the same. They start out with great tests, verifying that the simplest CRUD operations are covered. Then as the changes come, the tests fade away. Their big browser-driven tests are so slow, brittle, and difficult, the question of "should we test this?" becomes paramount as they try to convince themselves that their code doesn't need tests. And even the most ardent TDD proponents and green-band wearers are suffocated as they have to admit that, yes, for the business' sake we cannot spend days building a test harness to test if a new field is required.

I hope this article is the myth-buster to the fantasy world that the Rails community takes testing seriously.

-----


His code example is:

if (error_of_fifth_kind)

    goto fail;

     goto fail;  
if (error_of_sixth_kind)

    goto fail;
The_truly_important_code_handling_non_erroneous_case

My question: If the "truly important code" is really that important, where are the unit tests to verify that it "handles" the "non erroneous case????"

Test. Your. Code.

-----


Because Apple doesn't have a software testing culture. At least that's what I've been told by Apple engineers I know who used to work at Microsoft ("software testing is not the same respected discipline you're used to at Microsoft"), as well as when I interviewed with Apple and asked what kind of test team would be backing the product I would be working on (manual testing with no SDETs, apparently).

Take it as the quite anecdotal evidence it is, but to me it explains a lot.

-----


I agree that it's totally shocking that Apple did not have an example of each kind of bad cert. Even a rudimentary unit test of this code would have caught this bug. I bet they do now.

-----


But rudimentary testing of critical code is not part of Apple's corporate culture. They have released versions of the Finder with amateurish bugs that delete files[1] and versions of Mail that randomly delete messages[2]. Several versions of Mail on iPhone, a couple of iOS versions ago, send hundreds of copies of a message when emailing a link from Safari[3]. They've chosen to hoard over a hundred billion dollars in cash rather than hiring more competent engineers and enforcing quality control.

The blame for these fiascos, and for the goto fail bug, getting out the door lies not with the programmers, who can not avoid making mistakes, but the with the CEO and other management, who decide how to allocate resources.

[1]http://tomkarpik.com/articles/massive-data-loss-bug-in-leopa.... [2]http://discussions.apple.com/thread.jspa?messageID=12758081&.... [3]http://lee-phillips.org/iphoneUpgradeWarning-4-2-1/

-----


The thing that kills me is that rudimentary unit testing of simple functions like this makes development faster. You have to run the code, right? It's easier to run it in a unit test than to set up an environment to run the result.

My pet peeve is code that is so broken that it has obviously never even been run.

-----


> My pet peeve is code that is so broken that it has obviously never even been run.

Yeah...in my first support job I had to deal with a customer call that traced back to a install script for our company's (quite pricey, enterprise back-end) software dying with a syntax error.

-----


Also: just because you can omit braces, doesn't mean you should. Stick to 1TBS and this kind of mistake shouldn't happen.

-----


1TBS = One True Brace Style, had to look up that abbreviation [1]. Puts the `{` on the line with the `if`, `for`, `while` text and the `}` on its own line, and requires the braces even for one line blocks. (I knew the rest, just hadn't seen "1TBS" before.)

[1] http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS

-----


Agreed, but the author's point (indirectly, perhaps) is that requiring braces is an example of something that should be part of the language, and the fact that it's not should be considered a defect of the language.

-----


This mistake shouldn't happen?

Mistakes always happen. Even if I dedicated myself to using braces everywhere, my mistake might be that a) I put the braces in the wrong place, or b) I forgot to put the braces.

-----


Shouldn't != couldn't. In Haskell and the MLs, for instance, certain classes of mistakes shouldn't happen because of the type system and pattern matching, but a single wildcard could throw that off.

-----


I don't think your model has to have 1200 lines of code to see the benefits. DHH's ticket class stars with 2 lines of model code, which is a very rare case in the Rails applications I've seen. Counting by hand, I see DHH's example has one, two, three...

Twenty-six (26) lines of model code that are dedicated to validating this specific "confirmation" validation.

Given that validation is just one of the concerns of models built with The Rails Way, imagine sprinkling all of the other code that a model will have in-and-around these 26 lines of code. The central purpose of those 26 lines of code vanish into the fog of the rest of the model, creating the mystical behaviors that are common in some Rails applications.

I totally understand the concern about preemptive architecture, but once the code count for a given behavior creeps from 4, to 8, to 12... it's time to organize it into some sort of central place that's isolated from the rest. I mean, gosh, we know how this works in the real world, right?

Dev A: Here's my 26 lines of validation code to the model, DHH says it's the right thing to do.

Dev B (hours later): I need to add a little bit of behavior here, but I'm only adding a little bit of code. I'm not going to try to deduce what all of that code does, so I'll just tack mine on the bottom.

Dev C (days later): I have to add a bit of code... hmm... this is sort of a mess, I see mostly validation code but I also see some behavior. I'm not touching any of it. I'll just patch my stuff here... and here!

[iterate over and over, you get a mess of a Rails app]

I've seen this happen to multiple Rails applications... Rails applications built by experienced developers who know Rails in-and-out.

Plopping a bunch of code in something as important as a Rails model and leaving the cleanup for the next dev isn't very polite.

-----


I'm a fan of Ayn Rand and her books. But pointing out obvious issues with this article doesn't take a fan, it just takes someone who knows her work. It's not correct.

"Ayn Rand’s novel “Atlas Shrugged” fantasizes a world in which anti-government citizens reject taxes and regulations, and “stop the motor” by withdrawing themselves from the system of production."

Ayn Rand was not anti-government, nor did her heroes "withdraw themselves from the system of production." They continued to be very productive - they just moved away.

"Ayn Rand’s philosophy suggests that average working people are “takers.”

False, and absolutely unsubstantiated. I've read most of what she wrote, and nowhere is this suggested.

"In keeping with Ayn Rand’s assurance that “Money is the barometer of a society’s virtue,” the super-rich are relentless in their quest to make more money by eliminating taxes."

Ayn Rand did not advocating hoarding money for the sake of money. To her, money is a tool for trade amongst productive people. It's the production that matters, and money is just one of the potential results.

She wrote: "So long as men live together on earth and need means to deal with one another—their only substitute, if they abandon money, is the muzzle of a gun."

"Ayn Rand’s hero John Galt said, “We are on strike against those who believe that one man must exist for the sake of another.” In his world, Atlas has it easy, with only himself to think about."

Someone hasn't read the book, because John Galt didn't have it easy. This particular quote can be summarized simply by saying "Let us live our own lives."

-----


Totally agree. At best this rebase talk is navel-gazing, and at worst it's a technique that turns Git into a complicated, scary place for those just want to get work done.

I have introduced git and hg to many people, but I've always tried to tie it into what people do already. Without source control, practically everybody did the same thing: They'd work a little bit, they'd save, they'd work a little bit, they'd save... etc. Using branching for organizing work and a nice cheat-sheet of a few git commands, most non-technical people will be off-and-running.

It all works until the programmers make it complicated with the rebasing. The price of the tidy commit history is the loss of confidence of the rest of the team. I'd rather have the people.

Case in point: https://vimeo.com/60788996

-----


It's only complicated because people don't realize how it works. Half the people in this thread advocating to use rebase aren't saying when it's ok and when it's not ok and why.

When it's ok: You are working on your own line and the commits you've made are not in a central repo.

Why: Git commits are a hash tree and when you change one commit it changes all the SHAs that come after it. This makes git see your commits pushed remote as different then the ones that are local. The commits have the same changes so it puts duplicate conflict markers everywhere.

Most people love it once they realize how it works.

A lot of people use version control also as a backup in case their hard drive fails. Because of this they are scared of staying on a topic branch for very long, so they push then rebase often leading to conflicts which are scary.

https://en.wikipedia.org/wiki/Hash_tree

-----

More

Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: