Opened 13 years ago

Last modified 13 years ago

#170 closed defect (FIXED)

tests aren't all passing for me in gmg/master

Reported by: Caleb Davis Owned by:
Priority: minor Milestone:
Component: Keywords:
Cc: Parent Tickets:

Description

Anyone else getting this?

`http://dpaste.com/583321/ <http://dpaste.com/583321/>`_

I did an

::

    rm -rf mediagoblin

followed by a fresh gmg install + buildout and still get the same
result. No amount of migration/wiping/purging/meditation would make
it go away for me.



Change History (12)

comment:1 by Christopher Allan Webber, 13 years ago

Heya Caleb,

I definitely got the first error in the authentication views tests.
I fixed it and pushed up a change.

As for the other, I'm not getting it. I wonder if you can do two
things.

./runtests.sh --pdb --pdb-failures

when you get the prompt, could you grab the output of both:

document
expected\_document

and paste them in the tracker here or in a pastebin. That would
help debug this problem.

I wonder if the test migrations database isn't being wiped.



comment:2 by Caleb Davis, 13 years ago

yeah, still no joy on my end. strange...

Here are the test objects-

EDIT:

.. raw:: html

   <del>
   
`http://dpaste.com/584856 <http://dpaste.com/584856>`_

.. raw:: html

   </del>  
   
`http://dpaste.com/583856 <http://dpaste.com/583856>`_



comment:3 by Christopher Allan Webber, 13 years ago

Pasting in case that paste expires:

::

    vdfc@mimas:~/src/mediagoblin$ ./runtests.sh --pdb --pdb-failures
    Using ./bin/nosetests
    ..............> /home/vdfc/src/mediagoblin/mediagoblin/tests/tools.py(155)assert_db_meets_expected()
    -> assert document == expected_document  # make sure it matches
    (Pdb) document
    {u'is_demon': False, u'magical_powers': [], u'num_limbs': 100, u'_id': ObjectId('4e3717fcd7d1fe5f50000000'), u'name': u'centipede'}
    (Pdb) expected_document
    {'magical_powers': [], 'num_limbs': 100, '_id': ObjectId('4e3717fcd7d1fe5f50000000'), 'name': 'centipede'}



comment:4 by Christopher Allan Webber, 13 years ago

Hey Caleb, just realized... what version of mongodb are you
running? You can probably find out by running

::

    mongo --version



comment:5 by Caleb Davis, 13 years ago

db version v1.2.2, pdfile version 4.5 Mon Aug 1 21:07:49 git
version: nogitversion



comment:6 by Caleb Davis, 13 years ago

here's the text of the original error, so we have it after the
dpaste goes away:

::

    Using ./bin/nosetests
    ...E..........F..............................
    ======================================================================
    ERROR: Massive test function that all our registration-related views all work.
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/vdfc/src/mediagoblin/eggs/nose-1.1.2-py2.6.egg/nose/case.py", line 197, in runTest
        self.test(*self.arg)
      File "/home/vdfc/src/mediagoblin/eggs/nose-1.1.2-py2.6.egg/nose/util.py", line 622, in newfunc
        return func(*arg, **kw)
      File "/home/vdfc/src/mediagoblin/mediagoblin/tests/tools.py", line 118, in wrapper
        return func(test_app, *args, **kwargs)
      File "/home/vdfc/src/mediagoblin/mediagoblin/tests/test_auth.py", line 197, in test_register_views
        'mediagoblin/user_pages/user.html']
    KeyError: "'mediagoblin/user_pages/user.html'\n-------------------- >> begin captured stdout << ---------------------\n===== Email =====\nFrom address: notice@mediagoblin.example.org\nTo addresses: happygrrl@example.org\nSubject: GNU MediaGoblin - Verify your email!\n-- Body: --\n\nHi happygirl,\n\nto activate your GNU MediaGoblin account, open the following URL in your web browser\n\nhttp://localhost:80/auth/verify_email/?userid=4e36575ed7d1fe4f4d000004&token=f4791546-8453-4022-8891-ad903c1495ca\n\n--------------------- >> end captured stdout << ----------------------\n-------------------- >> begin captured logging << --------------------\nbeaker.container: DEBUG: data file /home/vdfc/src/mediagoblin/mediagoblin/tests/test_user_dev/beaker/sessions/data/container_file/5/5e/5ef21312c6a58e2972fe8750b051ded0.cache\nbeaker.container: DEBUG: data file /home/vdfc/src/mediagoblin/mediagoblin/tests/test_user_dev/beaker/sessions/data/container_file/5/5e/5ef21312c6a58e2972fe8750b051ded0.cache\nbeaker.container: DEBUG: data file /home/vdfc/src/mediagoblin/mediagoblin/tests/test_user_dev/beaker/sessions/data/container_file/5/5e/5ef21312c6a58e2972fe8750b051ded0.cache\n--------------------- >> end captured logging << ---------------------" 
    
    ======================================================================
    FAIL: Make sure that running the full migration suite from 0 updates
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/vdfc/src/mediagoblin/eggs/nose-1.1.2-py2.6.egg/nose/case.py", line 197, in runTest
        self.test(*self.arg)
      File "/home/vdfc/src/mediagoblin/mediagoblin/tests/test_migrations.py", line 324, in test_run_full_migrations
        self.db, EXPECTED_POST_MIGRATION_UNMIGRATED_DBDATA)
      File "/home/vdfc/src/mediagoblin/mediagoblin/tests/tools.py", line 152, in assert_db_meets_expected
        assert document == expected_document  # make sure it matches
    AssertionError
    
    ----------------------------------------------------------------------
    Ran 45 tests in 13.829s
    
    FAILED (errors=1, failures=1)



comment:7 by Christopher Allan Webber, 13 years ago

I found out what the cause was.

::

    @RegisterMigration(3, TEST_MIGRATION_REGISTRY)
    def creature_remove_is_demon(database):
        """ 
        It turns out we don't care much about whether creatures are demons
        or not.
        """ 
        database['creatures'].update(
            {'is_demon': {'$exists': True}},
            {'$unset': {'is_demon': 1}},
            multi=True)

'$unset' is v1.3+ of mongodb:
`http://www.mongodb.org/display/DOCS/Updating#Updating-%24unset <http://www.mongodb.org/display/DOCS/Updating#Updating-$unset>`_

As Caleb said earlier in this thread, he's running v1.2 something.

It looks like this is what comes with Ubuntu 10.04.

This leads us to a question: what version of mongodb are we going
to require at a minimum?

We could do "unset" manually but it will take a bit more effort and
will be less atomic.



comment:8 by Caleb Davis, 13 years ago

I'll update mongodb -
`http://www.mongodb.org/display/DOCS/Ubuntu+and+Debian+packages <http://www.mongodb.org/display/DOCS/Ubuntu+and+Debian+packages>`_

And in the future I'll probably just use debian/stable :)



comment:9 by Caleb Davis, 13 years ago

Any more thoughts on this? I'm inclined to require v1.3+.

If we can agree on that then we can make a new bug to identify
older versions on install, and


-  at least warn the user to update mongodb
-  bonus - provide yes/no options to update mongodb immediately



comment:10 by Christopher Allan Webber, 13 years ago

I'd say "no" to updating MongoDB automatically; we can't be sure of
the right update procedures for all the many OS options there are.

"Yes" to warning the user (maybe even bailing out?) if the version
is too old. Caleb, could you make such a bug and then close this
ticket?



comment:11 by Caleb Davis, 13 years ago

Status: NewClosed
opening new ticket to alert users to older versions of mongodb -
`#478 </issues/478>`_



comment:12 by Will Kahn-Greene, 13 years ago

The original url for this bug was http://bugs.foocorp.net/issues/462 .
Relations:
#185: related

Note: See TracTickets for help on using tickets.