• Registered: 2010-05-10
  • Posts: 14

Topic: How would you test this behavior with Rspec + Cucmber?

Hello!

I'm not new to rails but have never before done TDD or BDD.  With this project I am determined to learn.  I've read the RSpec book as well as plenty of stuff online.

I'm working with post creation and redirection.  When logged out and visiting new post, it should go to the login page, and after login go back to the create post page.  However, this should not be the case with all pages -- using Devise there is a default user path, so for example you might log in on the index page and once logged in arrive on your profile page.  So I want flexibility in where it ends up, and I want to be sure to cover the case where the session is not cleared properly, resulting in a login from the index page taking you to the new post page - bad!

A unit test for controllers doesn't make a whole lot of set -- as it would require testing the session arbitrarily rather than the behavior of the method.

I can't think of a good way with cucumber.  The most basic test would require being logged out, logging in at one particular place, logging out, going to another place, logging in, and verifying that the new page was not some particular place.  I suppose it would work, but it seems a bit contrived -- something only written after the bug shows up once.  I would not originally think to write it.

  • Registered: 2010-03-03
  • Posts: 469

Re: How would you test this behavior with Rspec + Cucmber?

pehrlich wrote:

The most basic test would require being logged out, logging in at one particular place, logging out, going to another place, logging in, and verifying that the new page was not some particular place.

I think you can split it into several scenarios.

1) You're logged out, you go to the new post page, you see login form, you submit it and you see a new post form.
2) You're logged in, you go to the new post page and you see a new post form.
3) You're logged out, you go to some other page that requires authentication, you see login form, you submit and and you see index page.
4) You're logged in and you go to some page requiring authentication, and you see that page.

Maybe you only need 1 and 3, maybe 1-3, maybe all 4.

And there's nothing wrong with speccing things like session manipulation in unit tests.

  • Registered: 2010-05-10
  • Posts: 14

Re: How would you test this behavior with Rspec + Cucmber?

Hello, and thanks for the run-down!

I'm not sure I like steps 3 and 4 though -- they test authentication pages outside of the feature.  Are single features supposed to be cross-feature?  It is no coincidence that there's a related practical issue - namely that I don't have any such pages made yet.

The trouble is that there's one special case beyond those four, which would require a test like this:

1) You're logged out, you go to the new post page, you see the login form, you submit it, you see the new post form, you log out, you go to the login page, you login, and you end up at the correct default page, which is known as of the writing of the test. (possibly a user profile)

The bug in my code, discovered through user testing (me), was that the session was not cleared, and in the last step I was taken instead to the new video page.

Obscure? Yes.  Contrived? No.  Normally I would just deal and move on -- no need for a fuss, but this is some of my very first test code.  It seems like a big scary leak coming unexpectedly from a system that promises a lot, and I'm concerned that I'm using it wrong.

A good idea, having discovered possible bug, is to write a test making sure the session is cleared.  But that doesn't make me any more secure for similar scenarios in the future.

Has there been any discussion on a test framework that not only confirms asserts, but watches for unasserted changes -- to the database, or session, or whatever.  Do you think such a thing would work, if made?

Cheers & Many thanks!
--Peter

  • Registered: 2010-03-03
  • Posts: 469

Re: How would you test this behavior with Rspec + Cucmber?

I would just move on without integration test for the case you've described. I'd say unit test is enough.

BDD is not a silver bullet either. You still have to maintain clean, readable and predictable code. And my personal opinion is that if you do - you don't actually need to cover each and every possible scenario. No tests give you 100% guarantee. And whatever tests you have - you still have to do user testing.

However test do help. Test are, besides they test things, the way to describe how the code is supposed to be used, what the common use cases are, the way to communicate to other developers working on that code and so on... Even though they don't guarantee there are no bugs, they are still VERY useful in practice... They save alot of time, especially after you get used to writing them.

Thats just an opinion... smile

  • Registered: 2010-03-03
  • Posts: 469

Re: How would you test this behavior with Rspec + Cucmber?

Has there been any discussion on a test framework that not only confirms asserts, but watches for unasserted changes -- to the database, or session, or whatever.  Do you think such a thing would work, if made?

I never heard about it. And I think it would be very hard to use. If the test framework watches for any changes made, you probably have to keep in mind all the side effects. It might make it hard to concentrate on the main thing to test.