You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
deftest_when_a_file_exists_in_the_source_but_not_the_destination():
withtempfile.TemporaryDirectory() assource,\
tempfile.TemporaryDirectory() asdest:
content="I am a very useful file"
(Path(source) /'my-file').write_text(content)
sync(source, dest)
expected_path=Path(dest) /'my-file'assertexpected_path.exists()
assertexpected_path.read_text() ==content
Another option is to use pytest's tmpdir fixture. That would reduce number of lines even more:
deftest_when_a_file_exists_in_the_source_but_not_the_destination(tmpdir):
source=tmpdir.mkdir("source")
dest=tmpdir.mkdir("dest")
source.join("my-file").write("I am a very useful file")
sync(source, dest)
dest.join("my-file").read() =="I am a very useful file"
And there is one more thing. I understand that these end-to-end test-cases are only for demonstration of the disadvantages of tightly coupled architecture, but they do not seem very realistic to me. I would use stubs for the end-to-end testing and I would have only one test-case for that, which would rather look like this:
this test still has the same problems and disadvantages of the original test-cases, like high cost of testing all business rules and inability to test them separately and in isolation. Which actually is not the use-case for end-to-end testing. I've just understood the source of my confusion. Chapter 3 started with creating "bad" end-to-end tests and replaced them with "good" unit and edge-to-edge tests at the end of the chapter by improving the architecture of sync function. So I was under impression that the message is that it is wrong to write end-to-end tests (well, maybe I'm just a bad reader). But the point, probably, is that with the initial architecture of sync it's impossible to write unit tests, and using end-to-end testing in unit-test maner is a bad idea.
The text was updated successfully, but these errors were encountered:
I did not know about tempfile.TemporaryDirectory, thanks very much for that! maybe we'll leave the listing deliberately ugly for now tho
yes you're right, the point is not "e2e tests are bad" but "using e2e tests to cover business logic / edge cases is bad (or at least annoying)" .
we try and say that a bit more in the service layer chapter section called 'what kinds of tests should I write'. we should say it more explicityly here too...
The following construction from Chapter 03 Example 3:
is a use-case for TemporaryDirectory context manager:
Another option is to use pytest's tmpdir fixture. That would reduce number of lines even more:
And there is one more thing. I understand that these end-to-end test-cases are only for demonstration of the disadvantages of tightly coupled architecture, but they do not seem very realistic to me. I would use stubs for the end-to-end testing and I would have only one test-case for that, which would rather look like this:
this test still has the same problems and disadvantages of the original test-cases, like high cost of testing all business rules and inability to test them separately and in isolation. Which actually is not the use-case for end-to-end testing. I've just understood the source of my confusion. Chapter 3 started with creating "bad" end-to-end tests and replaced them with "good" unit and edge-to-edge tests at the end of the chapter by improving the architecture of
sync
function. So I was under impression that the message is that it is wrong to write end-to-end tests (well, maybe I'm just a bad reader). But the point, probably, is that with the initial architecture ofsync
it's impossible to write unit tests, and using end-to-end testing in unit-test maner is a bad idea.The text was updated successfully, but these errors were encountered: