[PATCH 0 of 2 RFC] pullrequests: add unittests

[Mads Kiilerich]

On 02/21/2015 08:13 PM, Thomas De Schampheleire wrote:
> Hi,
>
> 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 
each other.

> 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.