What do you guys do in your system spec when you have pagination?
Example is
click_on "Creat"
visit "/records" # this is an index of all records but only the first 10 are shown and your record is kt there because there is pagination
expect(page).to have_text record.name # the record is created but it is not on this page. There is pagination and you should move to the next page
How do you approach this? Do you
Delete all records before the spec and know the record is always on the first page
Click on “next page” until you find your records.
The basic question should always be “What feature(s) are you trying to test?”, and the answer should always guide you when writing the spec. Assuming you want to test the paging of the dataset, I pre-populate with a specific set of records designed to test the features. The tests are things like “Does the first page start with the first record?”, “Does the page include the correct number of records?”, “Does the last page include the correct number of records (use a record count not divisible by page size)?”, “Are the correct buttons displayed on each page?”, etc. Test edge cases like “What is displayed when there are no records?” and “What is displayed when there’s only one page of records?”. If access rights are involved I’ll test things like “Are records included that should be?” and “Are records excluded that should be?”. If a user can add a record without displaying another page, I’ll ask “Is the display correct after the record is added?”
Thank you @jackrg for all the suggestions. These are good general suggestions.
Based on the exampme code, which is 1 to 1 as the real code, I am wondering what will you choose
Delete all records
Move through the pages to find your record
Note - you don’t know how many records are already in the db as other tests are ran in a random order before this one so there might be 0 or 100 records, you don’t know.
Rails by default executes tests in a transaction. This means if your DB starts out blank then when a new test starts there shouldn’t generally be data from previous tests in the system. Each test will add the records it needs and then at the end of the test all that data is rolled back.
So assuming you are not actually testing pagination and just wanting to test that your creation works you shouldn’t need to page through data. If that is the only record you created in that test then it should be the only record in your list and there is only one page.
That’s is true if this tests start out with a blank data. What I’ve found out through the years is that test with blank data are less useful than tests that are close to the real case - there are already record in the dB. This is close to production.
What I get is that you would prefer to clear the dB before the spec and run the spec on a clean environment, right?
Sorry I didn’t address that question directly. I use transactional fixtures, which means that every test will start with a fresh database. If you’re not doing that, then I would delete all records in target tables before the test. I would choose that over just resetting the database before each test because I have tables of lookups that are be pre-populated and it would be a pain to have to repopulate them before every test.
Others may be able to present better alternatives for clearing the database while retaining pre-populated tables, but the concept is the same, and if you use transactional fixtures there’s no need.
What I’ve found out through the years is that test with blank data are less useful than tests that are close to the real case - there are already record in the dB. This is close to production.
100% agree. But I wouldn’t rely on that existing data from prior to the test. Who knows what that will be and that could make the test flaky. If the correctness of the test depends on having a bunch of data (maybe you are testing the pagination) then I would do as @jackrg suggested and have fixtures of all that data that loads at the start of the test. That way the data is consistent every time you run the test.
My assumption was that your test on creating a record didn’t care about other records and therefore you didn’t need all that data for that test and therefore pagination wouldn’t come into play. But if it does then have your test load that fixture data.
