Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default to creating all the types of folders? #693

Closed
envygeeks opened this issue Feb 17, 2013 · 14 comments
Closed

Default to creating all the types of folders? #693

envygeeks opened this issue Feb 17, 2013 · 14 comments
Labels

Comments

@envygeeks
Copy link

It would be nice if you could provide the option to (or just do) create each folder for all the types of specs, the reason I ask this is because SimpleCov seems to not cover pieces unless their folders exist. For example it skipped over controller coverage completely until I created controllers, so it would be nice if all the folders existed by default so that coverage is properly handled or if a warning was put in the Readme about it.

/cc @colszowka

@alindeman
Copy link
Contributor

I think this is probably a good idea. Do you have time to work up a pull request?

@envygeeks
Copy link
Author

@alindeman I do tonight, so I'll see what I can put together.

@colszowka
Copy link

@envygeeks I'm a bit confused as to what you expect SimpleCov's output to be when you have no controllers yet and how rspec default folders add to that - could you please expand your example?

@envygeeks
Copy link
Author

@colszowka I had a ton of controllers but oddly it didn't start covering them until I created the controllers folder in my spec folder... I don't know who's fault it could have been (I assumed badly of course) that it was simplecovs fault but I was unable to replicate it so it might have been something else causing the problem the only thing I do know is the problem was resolved with the folder just being there.

@alindeman
Copy link
Contributor

@alindeman I do tonight, so I'll see what I can put together.

Were you able to work something up? :)

@vassilevsky
Copy link

OMG this is definitely the thing to do! I have been in a lot of doubt and confusion about which directories I should create under spec and what goes where. At first I thought there is no difference and everything just gets loaded and run; now I know that isn't the case and directories do have meanings. But then there's the support subdirectory where everything does just get loaded an run in no particular order. Oh my! RSpec does have to have a task that generates a skeleton for all the specs!!1

@dchelimsky
Copy link
Contributor

I had a ton of controllers but oddly it didn't start covering them until I created the controllers folder in my spec folder

Whether or not we add an option to GENERATE ALL THE FOLDERS ™, the behavior you're describing sounds like an issue w/ SimpleCov. I haven't used it yet myself (no offense, @colszowka - but I stopped using rcov long before SimpleCov came around) so I don't know the ins/outs, but it seems odd that SimpleCov would suddenly work when a directory under spec appears.

@colszowka
Copy link

Essentially there is no reason why SimpleCov should require this folder to be in place. The gem itself is entirely framework-agnostic and only should mind the code that has been loaded and executed after simplecov's been fired up. There is some additional goodness for rails, test/unit, rspec and cucumber in automatically naming test suites for the reports, but that's about as framework-specific as it gets.

What I can imagine is that the actual controllers were not being loaded by Rails before you added actual spec files that referenced their constants. With the default config.cache_classes = true this should not be the case, but for example at some point Spork recommended setting this to false. See Simplecov issues #42 and #60.

Maybe rspec-rails also has some automatic loading for matching spec/* vs. app/* dirs, that I do not know, but it could be another explanation why they didn't show up before.

If you have simplecov setup correctly, all the files that your source code requires after that should show up in the coverage report (files outside your project root get filtered out automatically so you don't get coverage for all your gems and STDLIB...). The STDLIB Coverage library which simplecov uses resets the coverage when files are required multiple times, which causes the issues with Spork, but I don't think this is the case here. So I'll make the bold claim: If it doesn't show up, it was not required.

@envygeeks
Copy link
Author

Such a long trip to dodge something.

@envygeeks
Copy link
Author

@dchelimsky @colszowka I don't actually know who's fault it was that this wasn't happening, actually I had badly assumed that it was SimpleCov's fault, but brought it here because if the fix was to just add a folder... so it was a 2 birds one stone type of scenario.

Though it could have been the fault of the software I use to run my tests (since I don't use RSpec autotest) I just haven't had time to look into it. I'm not blaming anybody really, so I hope nobody ever took this as a bug complaint, just a sort of feature request in the form of well this happened maybe we could do this since this fixed it, plus it doesn't hurt to do it!

@dchelimsky
Copy link
Contributor

plus it doesn't hurt to do it!

Actually it does, IMO. It's extra stuff to maintain in rspec, and not everybody uses every type of folder, so for many people this would just be extra noise.

@envygeeks
Copy link
Author

I don't see how a few folders inside of the template folder adds a lot of maint. I also only added the /basic/ folders.

@dchelimsky
Copy link
Contributor

Maintenance is not only in the code. What's basic to you is not basic to everybody, which means we'll have a feature that works for some folks and not for others, which means that others will ask us to make the feature configurable, since it's a feature we've committed to supporting, etc, etc. If we don't add the feature to begin with, none of that happens.

Also consider that these directories get created when you use the rails generator to generate a skeleton spec, so the problem of knowing where to put what is already solved.

So that leaves us choosing to solve a weird integration bug between rspec and simplecov that we don't understand yet by adding an otherwise low value hack to rspec. I don't think it's a great value proposition.

@envygeeks
Copy link
Author

Problem solved, happy day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants