3 ms·

> [0, 1, 2, -1, 10, 11, 12, 13, 14, -1, 26, 27, 28] What is that supposed to represent in terms of pagination? Are they cursors...? > I didn't think the code

> [0, 1, 2, -1, 10, 11, 12, 13, 14, -1, 26, 27, 28] What is that supposed to represent in terms of pagination? Are they cursors...? > I didn't think the code that generated the HTML from that was really worth testing because it was so superficial. For what it's worth (as a frontend person), pagination is traditionally one of the trickier things for us to make sure is working correctly. Off-by-one mistakes can happen for example (especially with zero-indexed items). Or sometimes the prev/next buttons don't correctly use the same math as the page 1, 2, 3, etc. buttons. It gets even harder if you don't know the total length in the beginning, or if you allow multiple page sizes or sorts/filters, or use lazy loading, etc. For those reasons I try to use a ready-built lib like MUI where all that is already tested internally (like https://github.com/mui/material-ui/blob/next/packages/mui-material/src/usePagination/usePagination.test.js https://github.com/mui/material-ui/blob/next/packages/mui-ma... or https://github.com/mui/material-ui/blob/next/packages/mui-base/src/TablePagination/TablePagination.test.tsx https://github.com/mui/material-ui/blob/next/packages/mui-ba...), but we still add our own automated and manual tests in our own usages. But then again I'm bad at math and division, lol, so maybe it's just my own weakness.

PaulHoule 2y ago
The paginator was one of the sources of stress in that project, it actually had me walk away from the keyboard and think about it a lot before deciding how to do it. Non-negative numbers are the index of the page starting at 0 and -1 is an ellipsis. This particular system in written in Python with Flask, I am using this CSS https://getbootstrap.com/docs/5.3/components/pagination/ https://getbootstrap.com/docs/5.3/components/pagination/ so 12 gets rewritten to <li class="page-item"><a class="page-link" href="?skip=12">12</a></li> As you point out this is the kind of code that has devilish complexity in the corner cases (benefits from having tests) but is also easy to test (no need for mocks, callback engineering, etc.) Some other examples like this are almost any kind of string parsing where off-by-one and other silly errors are so easy to make and where tests are so easy to write. Now you could also test the function that writes the HTML for "12" and it is pretty easy to do but the gain is small and it is also un-DRY because if you want to change the appearance of your HTML you have to change the test. (Granted, a good set of unit tests could prove that it's hard to sneak an HTML/JS injection in.) In the early 2000s there was a huge controversy over Mock Objects in Java testing. Back then you had to write your own Mocks so it was a lot of work which could be just as error prone as your own code. At the time it was also easy to get into test induced design deformation sneaking your mocks into code. 10 years or so later there was Mockito and also advances in dependency injection that made mocks ergonomic in Java in most cases.

PaulHoule 2y ago

The paginator was one of the sources of stress in that project, it actually had me walk away from the keyboard and think about it a lot before deciding how to do it. Non-negative numbers are the index of the page starting at 0 and -1 is an ellipsis. This particular system in written in Python with Flask, I am using this CSS https://getbootstrap.com/docs/5.3/components/pagination/ https://getbootstrap.com/docs/5.3/components/pagination/ so 12 gets rewritten to <li class="page-item"><a class="page-link" href="?skip=12">12</a></li> As you point out this is the kind of code that has devilish complexity in the corner cases (benefits from having tests) but is also easy to test (no need for mocks, callback engineering, etc.) Some other examples like this are almost any kind of string parsing where off-by-one and other silly errors are so easy to make and where tests are so easy to write. Now you could also test the function that writes the HTML for "12" and it is pretty easy to do but the gain is small and it is also un-DRY because if you want to change the appearance of your HTML you have to change the test. (Granted, a good set of unit tests could prove that it's hard to sneak an HTML/JS injection in.) In the early 2000s there was a huge controversy over Mock Objects in Java testing. Back then you had to write your own Mocks so it was a lot of work which could be just as error prone as your own code. At the time it was also easy to get into test induced design deformation sneaking your mocks into code. 10 years or so later there was Mockito and also advances in dependency injection that made mocks ergonomic in Java in most cases.