[PATCH 0/4] Some yarns
by Richard Maw
Repo: git://git.gitano.org.uk/personal/richardmaw/gitano.git
Ref: refs/heads/yarns
Sha1: 3789d955ef6f3d752f93db610a7de2c33851863b
This is my current progress for adding yarns,
based on what looked interesting at the time.
I'm thinking it may be a better idea to put a checklist on a trello card to
organise this.
Richard Maw (4):
testing: Remove yarn files for deprecated commands
testing: Test that project.owner can be set
testing: One weird tip discovered by test engineer to extend coverage,
LOC metrics hate him
testing: Add tests for rsync plugin
Makefile | 9 ++++-----
skel/gitano-admin/rules/defines.lace | 2 +-
testing/02-commands-config.yarn | 18 ++++++++++++++++++
testing/02-commands-rsync.yarn | 26 ++++++++++++++++++++++++++
testing/02-commands-set-description.yarn | 1 -
testing/02-commands-set-head.yarn | 1 -
testing/02-commands-set-owner.yarn | 1 -
testing/gitano-test-tool.in | 4 ++++
testing/library.yarn | 12 ++++++++++++
9 files changed, 65 insertions(+), 9 deletions(-)
create mode 100644 testing/02-commands-rsync.yarn
delete mode 100644 testing/02-commands-set-description.yarn
delete mode 100644 testing/02-commands-set-head.yarn
delete mode 100644 testing/02-commands-set-owner.yarn
--
1.9.1
7 years, 11 months
- 2
- 5
Breaking down "Moar Yarn-based testing" into missing yarns
by Richard Maw
I can see https://trello.com/c/NgjWZyc6 is a blocker,
so the first step is to work out what yarns need to be written.
This mail is partly to allow me to organise my own thoughts,
but I'd appreciate feedback.
The two areas we need to focus on are basic functionality fuzzing,
and regression testing,
so I'm mining the list of empty yarn files, and the commit log.
Empty yarns
===========
copy
----
I'm thinking the 3 main things we need to test here are:
1. Copying from a repo owned by the user,
to a path that the user also owns.
2. Copying from a repo owned by the user,
but still readable by them,
to a path that the user also owns.
3. Being denied the ability to copy a repository that exists,
but the user isn't allowed to read,
to a path that belongs to them.
4. Being denied the ability to copy a repo owned by the user,
to a path that doesn't belong to them.
count-objects
-------------
1. Count the objects for a repository owned by the user,
verifying that an object count and total size is shown.
2. Verify that you can't count the objects for a repository not owned by you,
since that would be a leak that it exists.
create
------
Basic functionality is assumed by basics, config, gc and ls yarns;
so ideally we would avoid re-testing that.
I think the only things usefully left to test are
1. Whether created repositories are owned by the right user.
2. Whether they are allowed or denied creation based on the ACLs.
destroy
-------
This is completely untested, requiring:
1. Destroy failing predictably for a repository that is known not to exist.
2. Destroy working for a repository owned by the user doing the deletion.
3. Destroy failing for a repository not writable by the user doing the deletion,
and that the error message denies it because it's not a writable repository,
rather than because it doesn't exist.
graveyard
---------
This requires the basics of destroy,
but it shouldn't overlap too much.
1. An Admin user can restore a repository deleted by another user,
to a path owned by that user, and then change its ownership to that user.
Potentially there's a hole in graveyard
where you could socially engineer a tired admin to ask you to restore a repo
to somewhere you're not allowed to create it yourself,
but I'm not sure we need to worry about that at this point.
2. An Admin can list deleted repositories.
3. An Admin can purge deleted repositories.
group
-----
This looks like it would be a big one,
since as well as testing that users can be put into groups,
ideally we should test whether that right can be delegated,
and that rights can be granted based on group membership.
Additionally, a previous bug was that if you removed a group that was a
subgroup of another group, it wouldn't remove the subgroup as a member
of the group, and produce unparseable config.
help
----
All I can think of for this is that you don't get an error when asking for help.
readme
------
1. Show the contents of the readme file for a readable repository.
2. Set the contents of the readme file for a writable repository,
and verify that the output is what was just set.
rename
------
1. Verify that after renaming, the same contents are in the new path.
2. Check that renaming a path that you aren't allowed to read gives EPERM,
rather than allowing, or ENOENT.
3. Check that renaming to a path you aren't allowed to write to is EPERM.
set-description set-head and set-owner
--------------------------------------
Since you intend to remove these commands,
any missing tests should go in the config yarns.
The only one I think is missing is:
1. `config $repo set project.owner $user`
sshkey
------
Everything depends on the standard instance,
which requires basic functionality to work.
I don't think we need any more than:
1. Extra keys can be added.
2. Extra keys can be deleted.
user
----
Basic functionality depends on user add working,
but everything else needs testing:
1. Non-administrators can't create users unless delegated by ACLs.
2. Created users can be deleted.
3. Changing the email or real name works.
4. Renaming a user works.
5. Renaming your own user works.
whoami
------
Basic functionality expects that this works,
and we don't really want to be parsing the output,
so I can't think of anything to test.
Untested features
==================
1. `auto_user_*` and `auto_group_*` ACL defines
2. gitano-setup with non-test options
3. Gitano HTTP interface
4. per git repository rsync repositories
5. Custom plugins, though testing behaviour that comes from in-tree
plugins is probably sufficient.
6. Password authentication
Also needs to re-test `whoami`, since anon access over HTTP is possible,
so seeing what it does without a key may be interesting.
7. Clod config availability to rulesets
8. Syslog, though I'm not sure how we'd do that.
9. Prefix, suffix and regular expression matching rules in ACL defines.
Fixed bugs without regression tests
===================================
1. `receive-pack` reports dangling HEAD after pushes.
We're currently missing yarns for most git commands entirely.
2. `as` reports the original user as the committer for config changes
Probably roll these into
3. Users and groups may have dots in their names.
Probably best to change the names used for testing,
so we know it works for all commands.
7 years, 12 months
- 2
- 3
- ← Newer
- 1
- Older →