Improve unit tests

[DecaTec]

• Existing unit tests need to be improved (mocking, etc.). The dependency of a real WebDAV server need to be removed.
• Add unit tests for better coverage.

[fubar-coder]

Maybe you can use NWebDav using ASP.NET Core using its test host? You can use ASP.NET Core in a .NET Framework project as long as you manually provide the libuv DLL for the correct platform (i.e. setting the test project platform from AnyCPU to e.g. x86) or you can convert the test project to .NET Core which - as of preview3 (or better: RC4) can target your .NET Framework project.

[TomGroeneboer]

Could you also please not use the infinity depth header on PropFindAsync in the UnitIntegrationTests?

Found in the following tests:

UIT_NetFx_WebDavClient_Copy
UIT_NetFx_WebDavClient_LockAndPutWithoutToken
UIT_NetFx_WebDavClient_LockAndPutWithToken
UIT_NetFx_WebDavClient_LockRefreshLockUnlock
UIT_NetFx_WebDavClient_Mkcol
UIT_NetFx_WebDavClient_Move
UIT_NetFx_WebDavClient_PropFind_AllProp
UIT_NetFx_WebDavClient_PropFind_NamedProperties
UIT_NetFx_WebDavClient_PropFind_PropName

[DecaTec]

@TomGroeneboer I'll keep this in mind. The unit integration test needs be be improved in general: I have to check the exact result (e.g. of a PropFind), not only if the result is not null and can be parsed.
This should ne done in a complete overhaul of the unit integration tests.

[DecaTec]

FYI: There is a bug in VS 2017 when running UnitTest in debug mode: microsoft/vstest#311
Currently the unit test will only work in release build.

[DecaTec]

@fubar-coder: I've tried to use NWebDav locally to run the unit test against. But unfortunately, it doesn't seem to support some scenarios. E.g. when trying to execute a propfind with depth 'infinity', you'll get following message: "Not allowed to obtain properties with infinite depth.".

So, I would need a (local) WebDAV server which can be integrated in the unit integration tests and supports every constellation one can think of.

I don't want to test a specific WebDAV server with my unit tests here. So I think I should mock the server side. On the other hand, this can be risky as I'm not testing "real world scenarios" then; when there is an error in the mocked WebDAV server, the library would also contain an error.

Any ideas about this issue are most appreciated... 😄

[DecaTec]

FYI: There is a bug in VS 2017 when running UnitTest in debug mode: microsoft/vstest#311
Currently the unit test will only work in release build.

With the lastest update of Visual Studio 2017, this bug is fixed. You can now run the unit tests in debug mode again.

[DecaTec]

I've made some tests mocking away the WebDAV server (IIS, Nextcloud, etc.), so that the request do not hit the network at all and that the unit integration tests can run "offline".

Using MockHttp seems to do the trick. Great project, btw. 👍

I've created a separate branch for this as it will take some time: https://github.com/DecaTec/Portable-WebDAV-Library/tree/unit-tests

However, I'll keep the unit integration tests which target a specific WebDAV server implementation, so everybody can run some tests against a specific WebDAV server.

[DecaTec]

I just branched the new unit-test branch into master.

I've decided to move the mocked test for WebDavClient to the unit test project, as they're not real unit integration tests no more.
The unit integration tests now contain all tests which can be run against a specific WebDAV server.

@TomGroeneboer Do you still need integration tests not using Infinity as depth? I'm not planning to expand the unit integration tests anymore. I've found out that every WebDAV server behaves a little different and writing integration test for every possible constellation would be a bottomless pit imho.

I'm concentrating on the (mocked) unit tests because they do not depend on any specific WebDAV server implementation.
The unit integration test project will stay more or less as a little "playground".

[DecaTec]

Finally resolved with d3b35f2