-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Provide a default _navigation_footer.html.erb #1450
Provide a default _navigation_footer.html.erb #1450
Conversation
@@ -0,0 +1,3 @@ | |||
Spree::Core::Engine.routes.draw do | |||
root to: lambda {|env| [200, {'Content-Type' => 'text/plain'}, ["Home page"]]} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Space between { and | missing.
Unused block argument - env. If it's necessary, use _ or _env as an argument name to indicate that it won't be used. Also consider using a proc without arguments instead of a lambda if you want it to accept any arguments but don't care about them.
Space inside { missing.
Operator => should be surrounded by a single space.
Space inside } missing.
Space missing inside }.
@@ -0,0 +1,3 @@ | |||
Spree::Core::Engine.routes.draw do | |||
root to: lambda {|env| [200, {'Content-Type' => 'text/plain'}, ["Home page"]]} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Space between { and | missing.
Unused block argument - env. If it's necessary, use _ or _env as an argument name to indicate that it won't be used. Also consider using a proc without arguments instead of a lambda if you want it to accept any arguments but don't care about them.
Space inside { missing.
Operator => should be surrounded by a single space.
Space inside } missing.
Space missing inside }.
soldius_auth_devise currently overrides with it's own. That's fine, but we can provide a default that should work fine for most custom auth solutions (rails g spree:custom_user)
48dc6a7
to
83e9a50
Compare
end | ||
end | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't you try writing a view spec. Those are usually easy to write, very fast, and you can mock the hell out of it. I don't think that you need to test rails routing, and that spree_logout_path
and such exist for real. It's a great overdo for such a view functionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay if the consensus is a view spec is correct and sufficient, I can do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
huh, under the new github system it looks like hound comments don't go away even if you fix em and force push? THAT's annoying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mtomov I'll change to a view spec, that does make sense, backend previously had no view specs at all, which is maybe what discouraged me from using it before. Hopefully that'll deal with the test failure from unreliable spec too.
Yeah, hopefully it won't require you to go through leaps and bounds to test On Mon, Sep 19, 2016 at 2:07 PM, Jonathan Rochkind <[email protected]
|
@mtomov switched to view spec. Github's recent changes seem to mean that rubocop's warnings that no longer apply to any code in this branch stay there forever, as does our comments on source code lines no longer in this branch. Kind of annoying. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the view specs very much, very easy to understand and follow 👍
require 'spec_helper' | ||
|
||
describe "spree/admin/shared/_navigation_footer", type: :view do | ||
let(:user) { create(:admin_user) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Theoretically, even Spree::User.new
should do fine here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible for an ordinary Spree::User to be viewing the admin backend at all? I guess it doesn't matter for a view test though.
I believe it does need to be a saved user (with an id) (or something mocked similarly), so generating a path to the admin user edit page for the user will work.
I am wary of mocking too much, because of other spree/solidus tests that mock so much they become unreliable.
I think it's prob okay the way it is, most 'realistic' test scenario, but if you require a different approach here just let me know. I suppose it can be create(:user)
, or a built non-saved user with it's id
mocked out so a path can still be generated.... that latter one is not attractive to me for several reasons though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spree.user_class.new
can be used. Of course, as you see fit. Just in terms of speed, not persisting data where possible I think is preferable.
And yeah .. making the start with the first view
spec is indeed the toughest, so great on doing that! Might encourage others to follow suite as they are easy to write, and quick to run.
I don't have anything else, maybe the others can have their say.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spree.user_class.new
is quicker than factorygirl? I guess it can be build
instead of create
if it doesn't need to persist, but I feel like it oughta be an admin user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, new
is faster. FactoryGirl.build
is marginally slower, as it will persist associated objects. For now though I think it's fine, let's deal with this in a subsequent PR. The answer to the conundrum would probably FactoryGirl.build_stubbed
.
I don't understand the CI failure, and think it is unrelated to this PR? |
expect(rendered).to have_link(Spree.t(:back_to_store), href: "/") | ||
end | ||
end | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra empty line detected at block body end.
ping? @mtomov? Anything else I can do? |
Looks good! |
<!-- solidus_auth_devise inserts a login_nav here. | ||
<ul id="login-nav" class="admin-login-nav"></ul> | ||
<!-- solidus_auth_devise replaces this partial with it's own login_nav. | ||
But we provide a defaut implementation below that should work with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo "defaut".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm for this despite the typo and the DB hit in the view spec.
require 'spec_helper' | ||
|
||
describe "spree/admin/shared/_navigation_footer", type: :view do | ||
let(:user) { create(:admin_user) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, new
is faster. FactoryGirl.build
is marginally slower, as it will persist associated objects. For now though I think it's fine, let's deal with this in a subsequent PR. The answer to the conundrum would probably FactoryGirl.build_stubbed
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
Caught in a PR review (solidusio#1450), and merged.
Prior to this PR,
backend/app/views/spree/admin/shared/_navigation_footer.html.erb
is an empty file, save for a comment.
solidus_auth_devise
overrides the partial to provide basic 'you are logged in as','logout' etc functionality in the admin sidebar.
However, there's nothing really devise-specific about this functionality.
We can easily implement it just in terms of ordinary spree, and the
methods that any auth solution is expected to provide, like
spree_logout_path
This will make it easier on custom auth, no reason to have to figure out what to do
here on your own to get equiv func to the
solidus_auth_devise
standard when wecan provide a default. Custom auth could still override this partial if wanted/needed, but
this default should ordinarily suffice.
solidus_auth_devise
can keep overriding it, we don't hurt it any by providing a defaultimplementation, instead of just a blank file, for it to replace.
The actual implementation here was straightforward -- figuring out how to test it
was a colossal pain. It's kind of kludgey in a couple ways, but I tried nearly many
approaches before arriving at what's here as least evil I could find.