[PATCH 0 of 2 RFC] pullrequests: add unittests
mads at kiilerich.com
Tue Feb 24 17:26:19 EST 2015
On 02/21/2015 08:13 PM, Thomas De Schampheleire wrote:
> This RFC is the beginning of adding a set of unittests for the existing
> behavior in _get_repo_refs.
> I would like to get feedback on the following:
> a. general feedback on the current code
Nice. Additional work can be added later.
> b. the next batch of tests is supposed to verify the behavior of
> _get_repo_refs for pull requests from a branch. For this I need to add a
> branch to the repository in the test, but I'm unsure how I should do this.
> Any help is appreciated here.
> Similar question for adding bookmarks (hg only?) and tags.
Ideally, it would be unit tests and we would have one of:
* a good way to either mock all the dependencies of the tested code (but
a realistic mocking of a repo is tricky), or
* an efficient way (in test-writing-time and execution-time) to create
test repositories (perhaps fully in memory), or
* "ready made" repos with relevant test cases where everything could be
tested (read-only or with roll-back)
Instead, we have to use some approximation (aka a hack).
I guess the simplest way is to create a new test repo in the test or the
setup part of it, try to reuse it across tests for efficiency, but also
trying to isolate any changes the tests might do so they don't influence
> Partially related to b. a good explanation on the repository handling in
> Kallithea is very welcome: there is obviously the real repository on
> filesystem, but in Kallithea I see different classes:
> - Repository
Lives in db.py .
This is the sqlalchemy class that defines that database fields and where
the ORM creates Python objects with more or less the same field names.
The db classes are models and can have logic ... but are sqlalchemy
classes and slightly magic.
> - RepoModel
Lives in repo.py ... but as you can see, it is tightly coupled to the db
classes by setting cls = Repository so the BaseModel class can help find
corresponding db instances.
I guess the idea with these other models is to have something more high
level and less database/ORM specific. It seems like the separation is
blurry. It could perhaps be clarified what goes where, or they could be
merged to one concept.
> - BaseRepository
This is the base class for MercurialRepository and GitRepository , for
actual creating VCS instances of the repos that are named in the database.
More information about the kallithea-general