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

Tests try to access the home directory of the user running the file #126

Open
satanas opened this issue Nov 9, 2014 · 2 comments
Open

Comments

@satanas
Copy link
Owner

satanas commented Nov 9, 2014

Nomadium comments:

Hi folks,

I'm looking for help with this bug. For full context, please take a
look at:

What is happening here is: a Debian autobuilder is unable to build
libturpial from source. This is a serious bug and has caused to get
turpial dropped from testing.

The autobuilder is failing because libturpial unit tests are trying to
write in the homedir of the user who is running the build and this
violates Debian guidelines (a package should not try to write outside
its builddir).

I was hacking the unit tests but I'm unable to get a reasonable fix
for this issue. The files with problematic unit tests are:

  • tests/test_column_manager.py
  • tests/test_account_manager.py
  • tests/test_core.py

I stumbled upon these two situations:

  • I tried to pass an explicit basedir to libturpial.config.AppConfig
    constructor to override the default basedir pointing to the homedir of
    the user running libturpial. I did this on tests/test_column_manager.py
    and tests/test_account_manager.py.
  • On tests/test_core.py I noticed that I can't specify an explicit
    basedir when you create an instance of libturpial.api.core.Core, so this
    is going to try to create ~user/.config/turpial.

I'm looking for help to get a fix or workaround for this issue.

@iferminm
Copy link
Contributor

iferminm commented Dec 3, 2014

Why don't we just mock the file? Will that be possible?

We shouldn't be creating files or making requests on unit tests anyways.

Will that be a reasonable fix?

@satanas
Copy link
Owner Author

satanas commented Dec 10, 2014

Yes, mocking should be fine, we just need to test that the module does what it has to do 👍

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

2 participants