Client Unit Tests

Learn about testing clients, design decisions, and expectations adapter.

Clients in external service testing

VCR is set up. Now, let’s make the Twitter integration work. As it stands, the test fails because the user data is not in the view at all. The test suggests that the user email and the Twitter avatar should be in the view, so let’s add them to the view file.

Design decisions

We have a design decision to make about how the application should interact with Twitter. There are many options, ranging from calling the gem and service directly from the view to placing the interaction within the User class.

Our design here tends toward more objects and structure because we’re using this avatar to stand in for a more complex third-party integration. The classes’ set might feel like overkill, but we want to demonstrate what this is like with all the moving parts.

Writing the test

With that throat-clearing out of the way, let’s write some tests. It seems like getting the Twitter avatar-image URL is a User responsibility.

When we last saw the view code for projects, we were busy writing JavaScript. In the interest of keeping this example simple, we’re going to move the code back into the ERB. Having to manage the image back down to the JavaScript is just going to be a distraction here.

Relevant view code

The relevant view code looks like this in app/views/projects/show.html.erb (we’ve added a reference to the task.user.avatar_url.) We’ve also removed the task-table class from the div surrounding the table, which will prevent the JavaScript from being activated here:

Get hands-on with 1400+ tech skills courses.