If you want to check your own code (that generated page contains right links) - then test the href property of the link in question. Something like that:
href = "http://www.amazon.com/The-RSpec-Book-Behaviour-Development/dp/1934356379"
page.should have_selector "a[href='#{href}']", text: "The Rspec Book"
If you want to check urls themselves (that you copied it right or that url still points to the right page) - then here it is relevant Capybara docs: Calling remote servers.
It's tricky getting your head around TDD (and BDD) but the book RSpec Book - BDD helped me a lot. Behaviour driven development is not exactly the same thing as TDD, but it is close and you have to think in a similar way.
100% test coverage is a fantasy and a waste of time. Your tests should serve a purpose, typically to give you confidence that the code you wrote works. Not absolute confidence, but some amount of confidence. TDD should be a tool, not a restriction.
If it's not making your work come out better, why are you doing it? More importantly, if you fail to produce useful code and lose the contract, those tests weren't too useful after all were they? It's a balance, and it sounds like you're on the wrong side.
If you're new to Rails, you can get a small dose of its opinionated creator's view on testing in this 37signals blog article on the topic. Small rules of thumb, but maybe something to push you in a new direction on the subject.
If you want to check your own code (that generated page contains right links) - then test the
hrefproperty of the link in question. Something like that:If you want to check urls themselves (that you copied it right or that url still points to the right page) - then here it is relevant Capybara docs: Calling remote servers.
It's tricky getting your head around TDD (and BDD) but the book RSpec Book - BDD helped me a lot. Behaviour driven development is not exactly the same thing as TDD, but it is close and you have to think in a similar way.
100% test coverage is a fantasy and a waste of time. Your tests should serve a purpose, typically to give you confidence that the code you wrote works. Not absolute confidence, but some amount of confidence. TDD should be a tool, not a restriction.
If it's not making your work come out better, why are you doing it? More importantly, if you fail to produce useful code and lose the contract, those tests weren't too useful after all were they? It's a balance, and it sounds like you're on the wrong side.
If you're new to Rails, you can get a small dose of its opinionated creator's view on testing in this 37signals blog article on the topic. Small rules of thumb, but maybe something to push you in a new direction on the subject.
There are also good references on improving your use of RSpec like betterspecs.org, The RSpec Book and Everyday Rails Testing with RSpec. Using it poorly can result in a lot of headache maintaining the specs.
Technically it's BDD, but I would recommend The RSpec Book because it does a good job of explaining concepts and has extended tutorials. The second section of the book covers Cucumber, so it will teach you that as well.
If you really want to research best practices for rspec some resources I use are: