Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Perceived enhancements to the sign up feature specs #25
I've made these changes to the sign up spec, which I perceive as enhancements. I am mainly measuring the enhancements through use of:
Originally, that looked something like:
After the changes I did, it looks like this:
Please let me know what you think!
I like the general idea of what you did here, there's definitely an improvement in the tests.
Two things come to mind:
visit '/' click_link 'Sign up'
If you go down the path of extracting your other code to a capybara helper, you could do the same for some of these:
# somewhere under spec/support def visit_sign_in_page visit '/' click_link 'Sign in' end # in our test before do visit_sign_in_page end
Thanks again for the collab.
I agree that it reads poorer. It seems to me that that is rspec's fault, not mine. If i didnt have to put "it" there, it would read great, it seems. :)
As for the "facility to get to the sign up page from some other page", it seems to me that that would belong in the feature spec of that page
I will name the process of visiting the sign up page as you suggested, thanks!
I would like to invite review and feedback of the signup feature spec from the people who have contributed code to Winni Vote so far: @floridaelago @stungeye @amirci @brett-anderson @gmcgibbon @swalberg @thetamind @celsodantas @jeffreyfultonca. When/if you have the time, please take a look.
This is now at a point where I'm happy with it. The only thing I can think of as a further enhancement would be to wrap the signup helpers in spec/features/support/signup.rb in a module, so that they are not in the global namespace, but I could not be bothered figuring out how to make that work, and it does not work when I simply wrap them in a module. Please let me know if you know how to achieve that, or any other feedback to make the specs better.
You are the people who I know are working on this project - please invite other group members if you feel they would benefit from looking at the example of how this feature is spec'ed out, or would have feedback.
Thank you for your time.
Dan, you need to add something like this to the
spec_helper.rb: we have the same thing on the same file and line already. Am I misunderstanding something there?
I've reviewed the list of commits, and I quite like the fact that most of the commits I made are separate. I've committed only when a logical step of the work I did was complete, except that failure cases are across e4716cf and 3d7950b. In other words, it seems that to squash the commits into one would remove insight into the steps I took to arrive at the current version. I think that insight can be valuable to others - what do you think?
Thanks again for your time.
Ah, ok, I must have misinterpreted what you said earlier on the
A separate list of commits is great during code review as it helps us understand the process that got you to the finished product. But when it's in master that information isn't as useful -- it can even be noisy. Just like the separate commits in the feature branch show your thought process, the larger commits in master should show how the product was built.
As a more practical example of why squashing is encouraged, sometimes a feature makes it to master and is found to be buggy in production. It's the feature that's buggy, not a particular commit from that feature. We want to be able to understand the feature as a whole and possibly
I'd never even heard of "squashing" before. This will be very useful to me
I've created a new pull request: #28 , which I think is properly set up for merging this in.