Skip to content
This repository has been archived by the owner on Mar 24, 2020. It is now read-only.

Fixes #464 - Add support of facet_default_uri for search result page … #497

Merged
merged 1 commit into from
Jul 26, 2018

Conversation

hweng
Copy link
Contributor

@hweng hweng commented Jul 23, 2018

…when using View Collection Items.

Fixes #464

Local Checklist

  • Tests written and passing locally?
  • Code style checked?
  • QA-ed locally?

What does this PR do?

When selecting "View Collection Items" from a collection landing page, the result list that the user is taken to defaults to "sort by Title"

@ucsdlib/developers - please review

@coveralls
Copy link

coveralls commented Jul 24, 2018

Coverage Status

Coverage increased (+0.008%) to 66.604% when pulling c6eb470 on default_sort into 3fb10b2 on develop.

@hweng
Copy link
Contributor Author

hweng commented Jul 25, 2018

@ucsdlib/developers - please review. Thanks!

first(:link, "View Collection Items").click

expect(page).to have_content("Sort: title")
expect(page).to_not have_content("Sort: relevance")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it also be worth having a check here that the two objects in this collection are indeed sorted by title?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mcritchlow The functionality of sort by title (by relevance and etc. ) is the blacklight built-in function. Here we want to make sure when load the page the result page has the "Sort: title" as default .
If sort: title displayed but the page is not actually sort by title, it will be blacklight built-in function bug. So Would it be redundant to write those tests again in our local app?

Copy link
Member

@mcritchlow mcritchlow Jul 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a very fair point. I suppose the main (only?) value-add that I can think of for adding an expect saying "I also expect this object to be shown before that object in the list" just makes it explicit that this is why we're making this change. If it wasn't a feature, or end-to-end test, I'd probably feel different.

But that said, your point is well taken, and I don't have strong feelings one way or the other. We could certainly leave it as-is.

@unit.save!
@aCollection = DamsAssembledCollection.create(pid: "xx4473712z", visibility: "public", titleValue: "testCollection" )
@aCollection.save!
@testObj1 = DamsObject.create(pid: "xx2801340v")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only one other thought, related to these test objects and my other comment re: confirming the objects are sorted by title.

It seems like what we need these objects to have, as far as metadata, is a title. Anything else seems fairly irrelevant for the purpose of testing this new feature. I'm not sure how much difference in time it takes to persist and index these fixture files, but one (soccomObject1) appears to be a complex object. Could we instead just create two simple test objects and specify the minimal metadata we need to satisfy confirming that they appear ordered by title?

Something like:

...
@obj1 = DamsObject.create!(pid: "xx00000001", titleValue: "A Title", <unit and collection URI's>)
@obj2 = DamsObject.create!(pid: "xx00000002", titleValue: "B Title", <unit and collection URI's>)
..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mcritchlow Yes, I'm updating the tests to create the test objects instead of loading the existing fixtures files. Thanks for the suggestion!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mcritchlow After looking into it, I think it doesn't need to create or load new set of objects because there is existing loaded objects which is sufficient for testing this new feature. I've updated my tests. Please review. Thanks!

…when using View Collection Items.

Fixed the failed tests.

Update tests.
@lsitu
Copy link
Member

lsitu commented Jul 26, 2018

👍

1 similar comment
@VivianChu
Copy link
Member

👍

@VivianChu VivianChu merged commit 681bcc2 into develop Jul 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants