i am shocked there are 2 votes for no space and 1 i'm not sure. it is so much less readable imo.

challenge: find a style guide for any major language that recommends no space.

a former coworker had something he called "the Covey Convincer" -- a reference to stephen covey of _7 habits_ fame.

it was a 2x4 with SYNERGIZE! plastered across it in magic marker.

I have never read a style guide, but for some reason that's what looks best to me.

They're not required in Python either (and are therefore almost never used for simple conditionals)

I don't get the appeal of spacing inside parens. It just seems like it makes it harder to tell what they're delimiting in expressions that are even slightly complicated:

from
http://www.koonsolo.com/news/dewitters-tao-of-coding/

i think that style guide has some good advice in general (which is why i have it bookmarked), however, i am strongly against this 'if' recommendation.

i do one of these two:

always the space after the 'if' imo
'if' isn't a function call

#SYNERGY has been said a lot around me recently, don't mind it, hasn't been abused

i have to say i am pretty surprised you beat that challenge.

(EDIT: I missed this disclaimer at the start of his post: "This guide describes the coding style that I developed over the years. My style isn’t very widespread. As a matter of fact, I don’t know anyone who comes even close to the weird way I program". So i don't think this counts as a win)

google style guide, all the classic C or C++ ones, etc -- i have never seen that recommended before. he should take his own advice:

if english text is our guide (and i think it's a good starting point), then "if" is its own word. the open paren is not part of the word "if". the parens are something we use to group the condition following it, to say "this whole thing is a unit". why are we bastardizing a perfectly good and clear english word which everyone is used to scanning and interpreting instantly into this hideous machine-language hybrid "if("

if" you continue the analogy", i think the point is clear.
if "you still don't see what i mean", then god help you.

EDIT: now i am really curious how preference would break down among all programmers. the question would obviously get insta-closed on SO by the killjoy moderators -- is this kind of thing allowed on "programmers.stackexchange"?

So I just wrote 12 (all pretty long/involved) feature specs in capybara to basically cover the entirety of an existing application in order to be able to (massively) refactor the structure of the app, leaving the top level untouched.

12 tests, 1:36 to run on my retina mbp. I'm sure that'll take longer on a CI server.

I had taken a testing course through thoughtbot (ninja rails dev shop) where they basically went through their testing process of high level specs first, and hitting unit tests when there's a no method error. I kind of love it since I know the user interaction isn't broken with solid confidence... but at a certain point the test suite gets too slow. Most of the apps they write at development shops never get super huge, so they just test everything to make sure it works when they ship it.

My last project we had 600 tests that took about 6 minutes to run. I don't know what is happening now, but that was getting unwieldy. I guess at a certain point you can refactor some tests, remove unnecessary ones, or split up the app into multiple apps (if possible).

I guess I'm just lamenting never having anyone teach me anything except blog posts/stackoverflow. Kind of hard to figure out this kind of stuff on your own.

only because i remember reading that guide and thinking to myself, "man this guy has some good advice, except for this piece of crap if statement"

i agree he contradicts himself in his reasoning

i'll bet you a donut that you're writing too many integration and end-to-end tests and not enough unit tests.

6 minutes actually isn't so bad as long as the suite is categorized appropriately. first you run unit tests; that takes seconds. then you either run the next level up or at this point you lean on your CI server to do the rest. (if the CI server is slower than your laptop, you are doing it wrong.)

if this is still too slow, you start running tests in parallel on a cluster to get the time down.

if you can't find more advice about test practices than you know what to do with, you're doing it wrong. look at the TDD guys, your Uncle Bobs and your Michael Featherses. read _Growing Object Oriented Software_. watch misko hevery's many talks.

I probably do write more end to end tests than necessary, but it does help me sleep at night.

Appreciate the insight.

http://forumserver.twoplustwo.com/30...stion-1364414/

i have an interview coming up that has an associated "take-home" section. i've only recently started programming learning (probably 3ish months out) but i can do some things in python, and i am well versed in VBA.

i was hoping (not for answers) but maybe some ideas on general direction as this really has been messing with my head for the week or so its been assigned to me. i thought of attempting a monte carlo sim in python but i'm not that familiar with numpy and i'm not sure how i'd contextualise it.

Nchabazam,
I'm surprised you've taken a liking to capybara. I hate factorygirl, rspec, capybara and especially cucumber.

I wind up with like 5x more test code than actual code and things are painfully slow.

There's no way to do TDD properly when you have to wait a lot of seconds or minutes between each test. If it doesn't happen in 1-2 seconds then I'm not going to use it IMO, anything more than that breaks me out of the zone.

What would you use for rails high level specs? I use rubytest in sublime 2 with zeus to make running tests really quick... 2-3 seconds to run one isn't a big deal for me, but I don't know anything else.

Has anybody here made a switch from Heroku to elsewhere? I just learned that their db only allows 20 connections, which seems frighteningly low. Their next db costs $60 per month. Add in one dyno and yikes.

I'm thinking about jumping to Linode. While it wouldn't hurt to learn a bit, I'm kind of nervous about admin on a Linux distro I'm not familiar with.

What's wrong with EC2?

I would just use test unit for unit tests. I don't see a problem with a few sprinkles of capybara too if you really need higher level tests.

I'm not sure I'm the best person to answer that though. All I know is, I personally think it's a waste of time to have a million tests and super high coverage unless the thing you're making requires it. I also think it's a huge waste of time to test things that's already been tested inside of the framework you're using.

Most tests I write are unit tests. I feel like most integration type tests will work if your models are well tested and work as intended. I sprinkle in some for peace of mind only when I really feel it's necessary.

I like test unit's style of assertion tests because the API isn't massive and you can still do everything you want to do. It feels like a ton of extra mental overhead to use something else.

Cucumber requires writing so much bs code that has nothing to do with testing your code but to help you setup test code to write the tests your code should be passing. The only good thing about cucumber is it helps you break out features into isolated "things" which is definitely awesome, but you don't need to use cucumber for that.

+1

Shoe, have we even disagreed on anything lately?

We're on a streak, don't jinx it.

I'm imagining both of you don't use/probably are a bit against full on TDD?

I'm finishing up a feature, but I'm test driving it for amusement. I'll post a counter argument in a few.

So I'm writing some boilerplate rails 4 code to use for future projects. I hate devise, so I'm building some of its functionality on my own.

This test took me about 2 minutes to write, and is literally walking me through everything I need to do like a small child. I consider myself a reasonably together guy, and this is easy boilerplate... but all the stuff I'm missing, or forgetting because it's slightly different in rails 4 than 3 is kind of crazy.

This test isn't perfect, and we could argue that it's testing too much, or whatever... but I'm convinced that this code will be working as intended once it passes.

I do think that maybe I could scrap it once it's done. Test drive a feature, then scrap the spec, just keeping some tests to walk through the critical paths of the application?

Then again, I did have to refactor an app at my last job where we split some views up into two namespaces. This broke pretty much every link in the app. Having tests there to make sure that every page was working was soooo nice in figuring out if we had missed anything, saved us a ton of time.

I think as long as we're testing we're doing better than most people.

Also, there need to be a ton of unit tests there for things like validations, and methods I create for account confirmations, or anything else. I can also test that the email I sent is properly working using email_spec gem (unit tests for emails).

I just think the above is a good way to cover my ass on writing a new feature.

I'm not really against it. If it works for you, great!

I've written about it before but I generally (not always) find it an inefficient way to work. Most of the time I move much faster writing tests right after I write code.

I'm not a full on TDD enthusiast but I believe tests are important and I do write them. They just don't happen to be written first most of the time. I only do end to end tests when it's seriously important.

For example, let's say you have a todo app and you wanted to test some functionality of the "show" controller action to make sure it works, I think this is a mistake most of the time.

Why should I bother testing that "When I click 'View details', then I should see 'some todo item' and it should be 'unchecked'". Tests like this IMO are pointless because rails already tested the crap out of the controller.

If I make a typo in the todo path then rails will let me know instantly because it won't run, and if I input an entirely incorrect path or screw up the show view template because of some user error then I'll see it when I test the feature out first hand. I tend to look at the end result of what I'm coding right after I think I'm done implementing a feature.

In your double name space situation I would have taken the approach that removes almost all user interaction. I would have just done a project wide search/replace to add in the name space. I don't think that is being unreasonable in this situation. I trust the tools I use to do the things they are supposed to do.

In your creating your own auth I don't think it's a bad idea to have high test coverage. It's something you plan to use in many different projects and maybe even down the line you'll release it as a gem. I think code like this should have a healthy mix of different test levels.

I agree that testing controllers is a waste of time. Same with testing existing gem functionality, assuming you did your research and saw it had good coverage/good support.

I guess it doesn't matter too much, as long as we're pretty confident in the end result. I see so many people ignore testing and paying for it down the road (badly), that I might be overcautious. But as I mentioned above, I think as long as you're testing, it's just a matter of preference.

I'm sure I'll change the way I test some as I build more and more different types of applications, for companies or different types of clients.