<div dir="ltr"><div><div><div><div><div><div><div><div><div>Sorry, I've just figured out it was about reading a file, but that's not really different, it's easier.<br><br></div>case 1, with "data1" I expect that "do_my_stuff1" is called when calling "do_all_my_stuff" for example.<br></div>you just can inject do_my_stuff1 and "data1" in "do_all_my_stuff"<br><br></div>next in case 2, with "data2" I expect that "do_my_stuff2" is called when calling "do_all_my_stuff".<br></div>Now you need to inject "do_my_stuff1" and "do_my_stuff2" as arguments to "do_all_my_stuff"...<br><br></div>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".<br></div>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)<br></div><div>To test this you just need to mock "my_new_object"<br><br></div><div>do you feel emergent design here ?<br></div><div><br></div>Why ?<br></div>The aim is to be able to change/adapt your code faster.<br></div>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.<br><div><div><div><br><br><br><br><br><br><br><div><div><div><div><br><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-09 12:50 GMT+02:00 Gregory Salvan <span dir="ltr"><<a href="mailto:apieum@gmail.com" target="_blank">apieum@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Ok let's try differently, I'll make assumptions about your case correct me if I'm wrong :)<br><br></div>It smells you're talking about BDD (TDD London school), in this case you're testing the behaviour of your functions.<br></div>For example you want to test in case1 if you're writing "data1" to a file.<br>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.<br></div>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".<br><br></div>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.<br></div>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".<br><br></div>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 ;)<br><div><div><br><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-05-09 12:21 GMT+02:00 David Palao <span dir="ltr"><<a href="mailto:dpalao.python@gmail.com" target="_blank">dpalao.python@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Gregory.<br>
Thank you, but it's not clear.<br>
First, my program is supposed to read a file and give an answer<br>
depending on the contents of the file. This is a functionality I want<br>
it to have.<br>
<br>
Now, concerning TDD, for unit tests, I agree with you. But when it<br>
comes to functional tests (or acceptance tests), I'm not testing a<br>
*single* function of my code. I'm doing kind of a global black-box<br>
test to ensure that the user will get the expected result. And I want<br>
to do provide the correct result under different conditions. Therefore<br>
I need to find a way to provide a fake environment for my (functional,<br>
acceptance, black-box) tests. What I understand about TDD is that<br>
although the speed of execution of the tests is important, speed means<br>
nothing if correctness is sacrificed. So if I want to simulate a<br>
situation where some file has different contents in it, I need to test<br>
the program in an environment where that file has those different<br>
values. I don't see a way around it. (I could go through the net and<br>
try to access a different system for each of the different properties<br>
I'm looking for, but that would be even worse, wouldn't it?)<br>
But maybe I'm missing something.<br>
<br>
Best.<br>
<div class="m_-4946879272575728578HOEnZb"><div class="m_-4946879272575728578h5"><br>
<br>
2017-05-09 11:55 GMT+02:00 Gregory Salvan <<a href="mailto:apieum@gmail.com" target="_blank">apieum@gmail.com</a>>:<br>
> Hello,<br>
> I've seen no answer concerning TDD, I'll try to give you one.<br>
> TDD means fast feedback, so tests must execute fast, and so you're looking<br>
> for a design that's testable without reading your data in files.<br>
> In the TDD point of view, you'll have a code design where data are raw<br>
> injected in the function you're testing and testing if data are well read is<br>
> a non sense (for TDD only)<br>
> Hope it's clear.<br>
><br>
><br>
><br>
><br>
><br>
> 2017-05-09 11:29 GMT+02:00 David Palao <<a href="mailto:dpalao.python@gmail.com" target="_blank">dpalao.python@gmail.com</a>>:<br>
>><br>
>> Hello,<br>
>> After playing around with systemfixtures, I don't find a way to make<br>
>> it work for my purposes.<br>
>> I'm inclined to think that chroot is the answer to my question (thank<br>
>> you, Johan, for pointing it out from the beginning).<br>
>><br>
>> As I explained in my first post, I need a way to provide a fake<br>
>> filesystem to my functional tests. What I mean by functional tests is<br>
>> testing from the point of view of the user. What I do for that is: I<br>
>> call the executable from within my FTs, catch the output and compare<br>
>> it with the expected output.<br>
>> To call the executable I use subprocess.Popen. In principle it should<br>
>> be possible to provide a fake fs to it but, isn't it, at the end of<br>
>> the day, the same as creating a chroot jail?<br>
>><br>
>> Unless there is an easy way to do what I need using systemfixtures (or<br>
>> fakefs), which I don't see, I think I will need to go to chroot (or<br>
>> docker). Any recommended tool to create a basic chroot jail with<br>
>> python in it that I can use to run my program and modify files in<br>
>> /proc?<br>
>><br>
>> Thanks in advance.<br>
>><br>
>> Best<br>
>><br>
>> 2017-01-24 15:08 GMT+01:00 Johan Olsen <<a href="mailto:ulf.johan.olsen@gmail.com" target="_blank">ulf.johan.olsen@gmail.com</a>>:<br>
>> > Hello,<br>
>> ><br>
>> > I would solve this by running my program in a chroot environment in some<br>
>> > way. Chroot is used to change the apparent root directory for some<br>
>> > running<br>
>> > process and its children. You can then set up a mock /proc under e.g.<br>
>> > /tmp/mock, and run your tests with chroot under pretense that /tmp/mock<br>
>> > is<br>
>> > your actual root folder. From python you can do this with os.chroot.<br>
>> ><br>
>> > Regards,<br>
>> > Johan Olsén<br>
>> ><br>
>> ><br>
>> ><br>
>> > 2017-01-24 14:51 GMT+01:00 David Palao <<a href="mailto:dpalao.python@gmail.com" target="_blank">dpalao.python@gmail.com</a>>:<br>
>> >><br>
>> >> Hello,<br>
>> >> I am writing a program that does something based on information read<br>
>> >> from /proc (the target OS is linux). But I have some problems figuring<br>
>> >> out how to mock the /proc filesystem, or at least, some files in it.<br>
>> >><br>
>> >> The rationale is that I want to change some files inside /proc to<br>
>> >> simulate different configurations of the host computer so that I can<br>
>> >> run my functional tests against those different configurations.<br>
>> >><br>
>> >> I was thinking in using docker for this task. But<br>
>> >> 1) this is offtopic here :)<br>
>> >> and<br>
>> >> 2) I would like to learn what is the standard way to deal with such<br>
>> >> situations. If there is a "standard way" at all... I mean, what am I<br>
>> >> supposed to do from the point of view of TDD?<br>
>> >><br>
>> >> I would appreciate if someone with experience in such problems could<br>
>> >> share some advice.<br>
>> >><br>
>> >> Best,<br>
>> >><br>
>> >><br>
>> >> David<br>
>> >><br>
>> >> ______________________________<wbr>_________________<br>
>> >> testing-in-python mailing list<br>
>> >> <a href="mailto:testing-in-python@lists.idyll.org" target="_blank">testing-in-python@lists.idyll.<wbr>org</a><br>
>> >> <a href="http://lists.idyll.org/listinfo/testing-in-python" rel="noreferrer" target="_blank">http://lists.idyll.org/listinf<wbr>o/testing-in-python</a><br>
>> ><br>
>> ><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> testing-in-python mailing list<br>
>> <a href="mailto:testing-in-python@lists.idyll.org" target="_blank">testing-in-python@lists.idyll.<wbr>org</a><br>
>> <a href="http://lists.idyll.org/listinfo/testing-in-python" rel="noreferrer" target="_blank">http://lists.idyll.org/listinf<wbr>o/testing-in-python</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>