Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mock the database in the unit test suite #77

Closed
dstufft opened this issue Oct 20, 2013 · 14 comments
Closed

Mock the database in the unit test suite #77

dstufft opened this issue Oct 20, 2013 · 14 comments

Comments

@dstufft
Copy link
Member

dstufft commented Oct 20, 2013

No description provided.

@ncoghlan
Copy link
Contributor

A potentially simpler approach is to use an in-memory sqlite database for
unit testing.

@dstufft
Copy link
Member Author

dstufft commented Oct 20, 2013

I don't plan on keeping compatibility with SQLite. Right now there is but once PyPI legacy is gone and I can modify the schema I plan to take advantage of PostgreSQL's advanced capabilities.

This is just for the unit tests though, the functional tests (which will test high level features/user stories) will still be required to be backed by a real database.

@ncoghlan
Copy link
Contributor

I suspect (but can't prove) that an sqlite compatible subset of the schema
will be easier to maintain than a lot of database mocks.

@dstufft
Copy link
Member Author

dstufft commented Oct 20, 2013

Possibly. I'm not worried about the speed of PostgreSQL mostly that it's annoying to have to type out the command. If I can't mock it then I'll probably just leave it as is.

@alex
Copy link
Member

alex commented Oct 20, 2013

Not mocks, fakes! Verified fakes ideally :) /cc @dreid

On Sun, Oct 20, 2013 at 3:08 PM, Donald Stufft [email protected]:

Possibly. I'm not worried about the speed of PostgreSQL mostly that it's
annoying to have to type out the command. If I can't mock it then I'll
probably just leave it as is.


Reply to this email directly or view it on GitHubhttps://github.com/dstufft/warehouse/issues/77#issuecomment-26684073
.

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

@dstufft
Copy link
Member Author

dstufft commented Oct 20, 2013

Well I'd want to verify that the method is calling the execute method with a particular query, so that would be a mock would it not?

@alex
Copy link
Member

alex commented Oct 20, 2013

Oh, if your'e going to do it that way, then yes it's a mock. I think having
a verified fake for the models layer is a saner approach.

On Sun, Oct 20, 2013 at 3:35 PM, Donald Stufft [email protected]:

Well I'd want to verify that the method is calling the execute method with
a particular query, so that would be a mock would it not?


Reply to this email directly or view it on GitHubhttps://github.com/dstufft/warehouse/issues/77#issuecomment-26684730
.

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

@dstufft
Copy link
Member Author

dstufft commented Oct 20, 2013

Hmm, well I have functions like this: https://github.com/dstufft/warehouse/blob/master/warehouse/packaging/models.py#L35-L39

And I need to test them, currently I test them by starting a transaction, filling in some data, testing the return of that function, then rolling back the transaction. My thought was to just replace the execute function with a Mock and verify that the query matches. How would your way work?

@alex
Copy link
Member

alex commented Oct 20, 2013

Basically you replace the models layer with a fake object that just keeps
the "database" in a dictionary.

On Sun, Oct 20, 2013 at 3:37 PM, Donald Stufft [email protected]:

Hmm, well I have functions like this:
https://github.com/dstufft/warehouse/blob/master/warehouse/packaging/models.py#L35-L39

And I need to test them, currently I test them by starting a transaction,
filling in some data, testing the return of that function, then rolling
back the transaction. My thought was to just replace the execute function
with a Mock and verify that the query matches. How would your way work?


Reply to this email directly or view it on GitHubhttps://github.com/dstufft/warehouse/issues/77#issuecomment-26684785
.

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

@dstufft
Copy link
Member Author

dstufft commented Oct 20, 2013

But how do I test the models layer itself?

@dstufft
Copy link
Member Author

dstufft commented Oct 20, 2013

I'm already stubbing out the models layer outside of tests of the model layer.

@alex
Copy link
Member

alex commented Oct 20, 2013

Ah, I'd test the models layer against the real DB; if you do anything
besides trivial queries testing the DB layer with mocks is just a mess, how
do you verify that:
https://bitbucket.org/pypa/pypi/src/e5fae2ee665bd38b51ff77026ff304e70dfc229c/store.py?at=default#cl-1154is
correct witha mock?

Alex

On Sun, Oct 20, 2013 at 3:38 PM, Donald Stufft [email protected]:

But how do I test the models layer itself?


Reply to this email directly or view it on GitHubhttps://github.com/dstufft/warehouse/issues/77#issuecomment-26684817
.

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

@dstufft
Copy link
Member Author

dstufft commented Oct 20, 2013

Hrm, I suppose complex queries would be a problem :/

@dstufft
Copy link
Member Author

dstufft commented Oct 20, 2013

Ok i've been sufficiently convinced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants