1. These should be grouped together into 3, instead of 4 lines.
2. We should be asserting against the topics page object - in this case it's called "topics" and it is an instance of `PageObject::Topics`, not the Rspec capybara object, that happens to be called "page". It's confusing, I know.
3. The style we should be asserting against that object is conversational, declarative, and of our own choosing ... so what do you think of something like: 

```ruby
expect(topic).to be_rated_as(1)
expect(topic).to be_able_to_unstar
```

:point_up: doesn't that read nice? That's benefit #1. It just reads like a nice statement. I expect the topic to be rated once. I expect the topic to be able to be unstarred.

Also, instead of putting the implementation into the test we can make a nice abstract api that can be easily changed inside the page object class. This is great for when things like ... contents of links change a lot, or maybe html format changes, etc. When those things change you have ONE place you know needs to change. Imagine a giant test with lots of copying and pasting of css selectors and link contents needing to be changed then the site goes through a redesign.

the `able_to_unstar?` method this will look for can have the two assertions pushed down into it checking for two things - that it has a link with "Unstar this topic" AND NOT have a link to "Star this topic"