[TIP] mocking a file in /proc

[David Palao]

Hi, Gregory.
Thank you, but it's not clear.
First, my program is supposed to read a file and give an answer
depending on the contents of the file. This is a functionality I want
it to have.

Now, concerning TDD, for unit tests, I agree with you. But when it
comes to functional tests (or acceptance tests), I'm not testing a
*single* function of my code. I'm doing kind of a global black-box
test to ensure that the user will get the expected result. And I want
to do provide the correct result under different conditions. Therefore
I need to find a way to provide a fake environment for my (functional,
acceptance, black-box) tests. What I understand about TDD is that
although the speed of execution of the tests is important, speed means
nothing if correctness is sacrificed. So if I want to simulate a
situation where some file has different contents in it, I need to test
the program in an environment where that file has those different
values. I don't see a way around it. (I could go through the net and
try to access a different system for each of the different properties
I'm looking for, but that would be even worse, wouldn't it?)
But maybe I'm missing something.

Best.


2017-05-09 11:55 GMT+02:00 Gregory Salvan <apieum at gmail.com>:
> Hello,
> I've seen no answer concerning TDD, I'll try to give you one.
> TDD means fast feedback, so tests must execute fast, and so you're looking
> for a design that's testable without reading your data in files.
> In the TDD point of view, you'll have a code design where data are raw
> injected in the function you're testing and testing if data are well read is
> a non sense (for TDD only)
> Hope it's clear.
>
>
>
>
>
> 2017-05-09 11:29 GMT+02:00 David Palao <dpalao.python at gmail.com>:
>>
>> Hello,
>> After playing around with systemfixtures, I don't find a way to make
>> it work for my purposes.
>> I'm inclined to think that chroot is the answer to my question (thank
>> you, Johan, for pointing it out from the beginning).
>>
>> As I  explained in my first post, I need a way to provide a fake
>> filesystem to my functional tests. What I mean by functional tests is
>> testing from the point of view of the user. What I do for that is: I
>> call the executable from within my FTs, catch the output and compare
>> it with the expected output.
>> To call the executable I use subprocess.Popen. In principle it should
>> be possible to provide a fake fs to it but, isn't it, at the end of
>> the day, the same as creating a chroot jail?
>>
>> Unless there is an easy way to do what I need using systemfixtures (or
>> fakefs), which I don't see, I think I will need to go to chroot (or
>> docker). Any recommended tool to create a basic chroot jail with
>> python in it that I can use to run my program and modify files in
>> /proc?
>>
>> Thanks in advance.
>>
>> Best
>>
>> 2017-01-24 15:08 GMT+01:00 Johan Olsen <ulf.johan.olsen at gmail.com>:
>> > Hello,
>> >
>> > I would solve this by running my program in a chroot environment in some
>> > way. Chroot is used to change the apparent root directory for some
>> > running
>> > process and its children. You can then set up a mock /proc under e.g.
>> > /tmp/mock, and run your tests with chroot under pretense that /tmp/mock
>> > is
>> > your actual root folder. From python you can do this with os.chroot.
>> >
>> > Regards,
>> > Johan Olsén
>> >
>> >
>> >
>> > 2017-01-24 14:51 GMT+01:00 David Palao <dpalao.python at gmail.com>:
>> >>
>> >> Hello,
>> >> I am writing a program that does something based on information read
>> >> from /proc (the target OS is linux). But I have some problems figuring
>> >> out how to mock the /proc filesystem, or at least, some files in it.
>> >>
>> >> The rationale is that I want to change some files inside /proc to
>> >> simulate different configurations of the host computer so that I can
>> >> run my functional tests against those different configurations.
>> >>
>> >> I was thinking in using docker for this task. But
>> >> 1) this is offtopic here :)
>> >> and
>> >> 2) I would like to learn what is the standard way to deal with such
>> >> situations. If there is a "standard way" at all... I mean, what am I
>> >> supposed to do from the point of view of TDD?
>> >>
>> >> I would appreciate if someone with experience in such problems could
>> >> share some advice.
>> >>
>> >> Best,
>> >>
>> >>
>> >> David
>> >>
>> >> _______________________________________________
>> >> testing-in-python mailing list
>> >> testing-in-python at lists.idyll.org
>> >> http://lists.idyll.org/listinfo/testing-in-python
>> >
>> >
>>
>> _______________________________________________
>> testing-in-python mailing list
>> testing-in-python at lists.idyll.org
>> http://lists.idyll.org/listinfo/testing-in-python
>
>