Destroy_spec.rb test is failing, not sure what's happening.

Weird. I downloaded the files for the project and it all works fine. And your code is exactly the same. Can you upload to github and link your project here so that I could test it? The fault has to be somewhere else.

Yeah, when I click destroy it gets rid of the list just fine. Thanks for looking into this so closely!

Super weird: I downloaded the files from Treehouse, set it up in the VM, and it ran fine. Just in case, I also tried copying and pasting the index.html.erb file from one to the other, because I knew that we mucked around with the todo_list_id over there as well.

At any rate, I threw it up on Github now! If nothing else, this is helping me dive into Git more as well, which is awesome. I'm going to continue the project even with the broken code, and then figure out how to fix it up later if we can figure out what the heck is happening.

Thanks for your close attention, Maciej and Tom! This is awesome.

Time for the weirdest thing ever: I downloaded the code, did bundle install, migrated the database in dev and test environments and it all works fine (aside from controller tests, I had to add the description to the let! in the spec, like Jason does later in the video). They work fine when I type rspec and when I run bin/rake.

I now suspect that your test database did not clean after itself at some point during a test and there is still one object in it for some reason. Try doing this in the console:

rake db:reset RAILS_ENV=test

It should give you output like this:

-- create_table("todo_lists", {:force=>true})
   -> 0.0063s
-- initialize_schema_migrations_table()
   -> 0.0064s

And then run the test again. Let me know if this changed anything.

Wow wow wow! That was it! Thank you so much!

Any further reading you can point me to as far as your test database did not clean after itself at some point during a test? I want to make sure I fully understand what was happening here.

So in general you have three different databases: one for development (it's the one you're playing around with when you run rails console or when you run rails server on your computer), one for tests (this one is used by all the specs) and production (this one will run when you deploy your app on a server, so that the users won't see your test data ;) ).

In theory, the test database should clean itself after every single test (i.e. if it created an object and performed a test on it, it should destroy that object after the test). But for various reasons it may more or less randomly happen that some things ale left behind after a test. This is apparently what happened here.

When you run things like rake db:migrate, by itself, in most cases, this only applies to the development database. You sometimes have to run this command separately for test database, so you add the RAILS_ENV=test at the end.

The rake db:reset command drops your whole database, creates it again and runs all migrations from scratch, so you get a fresh database. This time you needed it with RAILS_ENV=test to make sure the test database got purged :)

I'm happy this worked. Continue your Rails quest and don't be afraid to ask on forums if things don't work ;). I'm usually around whenever I sit in front of my computer, which is quite often.

Fantastic explanation--thanks again!

rake db:reset RAILS_ENV=test This worked for me also, there must be a bug in the version of Rspec I am using maybe? Rspec -v 2.99.2 if anyone is interested.

I got the same result using rake db:reset RAILS_ENV=test

Just to test things out, I changed the let! created title an description from "Groceries" to "Tacos" and ran the test again. With the new title and description, the following test passed:

expect(page).to_not have_content(todo_list.title)

Further suggesting that the Groceries list was stuck in the database.

But the second, following, test still failed:

expect(TodoList.count).to eq(0)

It produced an error showing that the database has two entries in it, not zero.

So, yeah. The test database never cleared for some reason. It still had two entries stuck around for some reason. But the reset fixed all that.

Interestingly, running the rspec test a second time did not produce an error. So the db problem appears not to be originating with this particular test.

Would it be a good idea to bake that db:reset into the test itself?

The second hash is Ruby's evaluation inside the string (you know, whatever is inside #{} gets evaluated and inserted into the string; the {} itself won't work). The original code uses it as well and it works fine there.

I tried this just in case! It didn't work, and threw a new error about CSS syntax.

And me!