I’ve always written my meteor methods tests on neither client nor server, which means they run on both. I sometimes encounter frustrating errors when they run on the client, and am left wondering what the real benefit of it all is. It feels like I spend a lot of time stubbing and mocking packages and environments to make it work, when there might actually be no advantage of doing it.
I saw that MDG moved its method tests to be server only in their Todo’s repo:
So I’m wondering what the best practice is, am I detecting additional errors in my methods by running the tests on the client as well?
2 Likes
If you really want to be sure that latency compensation works then yes. If not, then stick to the server. In any case, server has the main priority.
Theoretically teating everything is considered a best practice. In practice its not, because so.e things are just not worth the effort. Especcially if they will not break anything.
I might be cursing here, but its the reality in businesses. There’s likely more mission critical bugs to solve or features to add
Was literally just writing almost the same thing as @cloudspider.
Unless you need latency compensation, I’ve found that using the methods basically as a wrapper for the server functions makes everything cleaner and easier to test. I like validated methods, as you get mixins and schemas out of the box, but the testing issues are a legitimate problem, I think.
1 Like
Awesome, thanks for both your inputs!