Tests should be added for any function containing logic that might become broken in the future. For example:
createUserRSSFeed - both flavours
fetchUserId - normal case and does not exist case
fetchUserTweets - ensure that Tweets are filtered correctly
withCache - the following cases:
cache exists
callback throws an error
callback produces an invalid result
invalidateOnError is false
cache does not exist
To test functions that contain hardcoded fetch calls, add a stubFetch?: () => Promise<TWhatever> option that overrides the fetch.
It would also be a good idea to add integration tests that call /:username and /:username/rss directly. Since the access tokens are hardcoded, there's no need to stub the Twitter API; we can use live data.
Tests should be added for any function containing logic that might become broken in the future. For example:
createUserRSSFeed- both flavoursfetchUserId- normal case and does not exist casefetchUserTweets- ensure that Tweets are filtered correctlywithCache- the following cases:invalidateOnErroris falseTo test functions that contain hardcoded
fetchcalls, add astubFetch?: () => Promise<TWhatever>option that overrides the fetch.It would also be a good idea to add integration tests that call
/:usernameand/:username/rssdirectly. Since the access tokens are hardcoded, there's no need to stub the Twitter API; we can use live data.