[TIP] mocking a file in /proc

Tue May 9 04:30:51 PDT 2017

Sorry, I've just figured out it was about reading a file, but that's not
really different, it's easier.

case 1, with "data1" I expect that "do_my_stuff1" is called when calling
"do_all_my_stuff" for example.
you just can inject do_my_stuff1 and "data1" in "do_all_my_stuff"

next in case 2, with "data2" I expect that "do_my_stuff2" is called when
calling "do_all_my_stuff".
Now you need to inject "do_my_stuff1" and "do_my_stuff2" as arguments to
"do_all_my_stuff"...

Continuing this way you'll see a pattern and with refactoring you'll be
able to remove a long list of arguments in "do_all_my_stuff".
Generraly this means the creation of a new type of object and a call on
differents methods: "my_new_object.do_my_stuff1" and
"my_new_object.do_my_stuff2" and do_all_my_stuff(data,
my_new_type_of_object)
To test this you just need to mock "my_new_object"

do you feel emergent design here ?

Why ?
The aim is to be able to change/adapt your code faster.
If you've got a new case that require a different behaviour, just create a
new type of object with the same methods than "my_new_object" and inject it
in "do_all_my_stuff" instead, require less changes to your code.

2017-05-09 12:50 GMT+02:00 Gregory Salvan <apieum at gmail.com>:

> Ok let's try differently, I'll make assumptions about your case correct me
> if I'm wrong :)
>
> It smells you're talking about BDD (TDD London school), in this case
> you're testing the behaviour of your functions.
> For example you want to test in case1 if you're writing "data1" to a file.
> I would just mock a file object I'll inject in the function (let's call it
> "do_my_stuff1") responsible to do this job.
> do_my_stuff1 will take a file_object as argument and by mocking this file
> object you're able to test if "write" method is called with "data1".
>
> Let's do with a more complex example, you want to be ensured that "data2"
> are written to file "filename2", in this case you'll inject the function
> that make the file_object and the filename.
> do_my_stuff2 will take 2 arguments: a function and a file name, by mocking
> the function in your tests you're able to check if it's called with
> "filename2" and if the method "write" of the returned object is called with
> "data2".
>
> It's to generic to have complex examples, but you really can test
> everything without writing data in files, and it's not really relevant to
> test if data are really written as it's the same as testing if there's no
> errors in python "open" implementation. I think we can trust python
> developpers for that ;)
>
>
>
> 2017-05-09 12:21 GMT+02:00 David Palao <dpalao.python at gmail.com>:
>
>> 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
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20170509/2a71db5d/attachment-0001.htm>