You might suspect that the URIs will look like/users/1/following and /users/1/followers, and that is exactly what the code in Listing 11.18 does. Since both pages will be showing data, we use get to arrange for the URIs to respond to GET requests (as required by the REST convention for such pages), and the member method means that the routes respond to URIs containing the user id. The other possibility, collection, works without the id, so that

would respond to the URI /users/tigers (presumably to display all the tigers in our application). For more details on such routing options, see the Rails Guides article entitled ‘‘Rails Routing from the Outside In.’’ A table of the routes generated by Listing 11.18 appears in Table 11.1; note the named routes for the followed user and followers pages, which we’ll put to use shortly. The unfortunate hybrid usage in the ‘‘following’’ route is forced by our choice to use the unambiguous ‘‘followed users’’ terminology along with the ‘‘following’’ usage from Twitter. Since the former would lead to routes of the form followed_users_user_path, which sounds strange, we’ve opted for the latter in the context of Table 11.1, yielding following_user_path.

With the routes defined, we are now in a position to make tests for the stats partial. (We could have written the tests first, but the named routes would have been hard to motivate without the updated routes file.) The stats partial will appear on both the profile page and the Home page; Listing 11.19 opts to test it on the latter.