Re:Ask HN: Is there a React test framework that actually works?
by PaulHoule on Friday May 24, 2024 @02:41PM
(#40469200)
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
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.
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/
so 12 gets rewritten to
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.