So that means all tests in test_backend.py and a blank class definition in test_backend_sql.py.
Certain test require some pre-existing db records. Normally we should do it in setUp method, but I think in keystone we have do it some other way. Should it be in a non-test method within the class and that method can be called everytime there is such requirement of pre-existing db records. Is this correct or am I missing anything? What about deleting those records? Should I do it explicitly or it will be automatically taken care in tearDown? ________________________________ From: Dolph Mathews <[email protected]> To: Akshat Kakkar <[email protected]> Cc: Adam Young <[email protected]>; OpenStack Development Mailing List <[email protected]> Sent: Tuesday, 16 July 2013 5:30 PM Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods? On Tue, Jul 16, 2013 at 8:23 AM, Akshat Kakkar <[email protected]> wrote: If I follow tests for "Catalog", I see that only one test is overwritten in test_backend_sql.py while the remaining 2 test are new (i.e. not declared in test_backend.py). I am only having SQL driver interface. So, should I write any test in test_backend.py or not? > Yes. Can I write tests only in test_backend_sql.py and a blank class definition in test_backend.py and nothing anywhere else? > No; do it the other way around, even if you only have one driver implementation. What all care should I take in doing this? > Feel free to put what you have up for review (consider maintaining it as WIP) and we can give you some more specific direction from there. > > >________________________________ > From: Dolph Mathews <[email protected]> >To: Akshat Kakkar <[email protected]> >Cc: Adam Young <[email protected]>; OpenStack Development Mailing List ><[email protected]> >Sent: Monday, 15 July 2013 5:44 PM > >Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods? > > > > > >On Mon, Jul 15, 2013 at 9:36 AM, Akshat Kakkar <[email protected]> wrote: > >As in my methods, I do not pass session object from outside so I am followin >the unit test for catalog. But what I am unable to understand is that there >are some test in test_backend.py and some in test_backend_sql.py. What is the >difference in between the two? > > >Tests in test_backend.py are run against all implementations of a driver's >interface (KVS, SQL, LDAP, memcache, etc). Each driver type has a module (e.g. >test_backend_sql.py) that sets up & tears down a backend for the driver, >inherits tests from test_backend.py, overwrites/extends tests as necessary to >document exceptions to the expected behavior (e.g. LDAP doesn't support >multiple domains). Follow the inheritance hierarchy for any given class in >test_backend_sql.py to illustrate. > > >> >> >>________________________________ >> From: Adam Young <[email protected]> >>To: Akshat Kakkar <[email protected]> >>Cc: OpenStack Development Mailing List <[email protected]>; >>"[email protected]" <[email protected]> >>Sent: Thursday, 11 July 2013 4:29 PM >> >>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db >>methods? >> >> >> >>On 07/11/2013 05:23 AM, Akshat Kakkar wrote: >> >> >>>The methods of read/write/update/delete of records in the tables are written >>>using SQLalchemy only and no direct sql is used. >>> >>> >>>I have implemented the things on the lines of trusts only. Similar to >>>trusts, I am also having RESTful APIs and unit tests for them are >>>succesfully written. In test_backend_sql.py, it is seen that no unit tests >>>are defined for trusts. So, it's confusing for me to implement the unit test >>>for my backend sql code. >>Yeah, trusts themselves are pretty simple as far as REST, and they are exercised via the Token backend code as well as test_auth.py and test_v3_auth.py. >> >>Look at the tests for identity and catalog, those should be a better example to follow. >> >> >> >> >>> >>>I know I am confusing the things and I apologise for that, but I am asking >>>because of that confusion only! >>> >>> >>> >>> >>>________________________________ >>> From: Adam Young <[email protected]> >>>To: [email protected] >>>Sent: Thursday, 11 July 2013 4:28 AM >>>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db >>>methods? >>> >>> >>> >>>On 07/10/2013 06:56 AM, Akshat Kakkar wrote: >>> >>>I have added 2 tables to keystone. >>>This should be done in a migration, and should be tested using the test_db_update.py file. >>> >>> >>>I have methods which do the read/write/update/delete of records in these >>>tables. PLease explain. We are not doing direct sql, but rather using SQLalchemy. >>> >>> >>> >>>I want to write unit test for all this. These methods of mine inherit from >>>keystone.common.sql and hence any call that these methods will make will go >>>to the db returned by keystone.common.sql when creating a session. For >>>writing a unit test this db should be a test db and not the production db. >>>So, how can I have a session of test db? or is there altogether a different >>>way of writing the unit test. >>>> See test_backend_sql.py >>> >>> >>>> >>>> >>>> >>>> >>>>________________________________ >>>> From: Dolph Mathews <[email protected]> >>>>To: Akshat Kakkar <[email protected]>; OpenStack Development Mailing >>>>List <[email protected]>see >>>>Sent: Tuesday, 9 July 2013 7:39 PM >>>>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db >>>>methods? >>>> >>>> >>>> >>>>I'm assuming you're referring to testing backend drivers as opposed to >>>>database migrations (tests/test_sql_upgrade.py). >>>> >>>> >>>>Backend agnostic tests land in tests/test_backend.py. Backend-specific >>>>tests, overrides, etc belong in tests/test_backend_sql.py, >>>>tests/test_backend_kvs.py, etc. >>>> >>>> >>>>Generally, you can't assume that keystone is backed by a database, however, >>>>as it's entirely possible to deploy without one. >>>> >>>> >>>> >>>>On Tue, Jul 9, 2013 at 10:55 AM, Akshat Kakkar <[email protected]> >>>>wrote: >>>> >>>>How to write unit tests in keystone for the methods which are directly >>>>calling the backend db? I understand that for testing purpose it should be >>>>a *fake db*, but how to do that in keystone? >>>>> >>>>>_______________________________________________ >>>>>OpenStack-dev mailing list >>>>>[email protected] >>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> -Dolph >>>> >>>> >>>> >>>> >>>>_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>>_______________________________________________ >>>OpenStack-dev mailing list >>>[email protected] >>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >> >> >> > > > >-- > > >-Dolph > > -- -Dolph
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
