MockFileSystemWatcher #854

Activity

1. CallumECameron

   added

   state: needs discussionIssues that need further discussionIssues that need further discussion

   type: enhancementIssues that propose new functionalityIssues that propose new functionality

   on May 24, 2022
2. fgreinacher commented on May 27, 2022

   

   fgreinacher

   on May 27, 2022

   Contributor

   More actions

   Thanks for writing the issue!

   We already discussed this and came to the conclusion that we don't want it in the core library. My suggestion here would be to use the existing extensibility points and provide your own implementation.
3. fgreinacher

   closed this as completedon May 27, 2022
4. fgreinacher

   added

   area: testinghelpersIssues that address the testing helpersIssues that address the testing helpers

   state: won't doIssues that won't be addressed. Reasons differ and will be provided as comments.Issues that won't be addressed. Reasons differ and will be provided as comments.

   and removed

   state: needs discussionIssues that need further discussionIssues that need further discussion

   on May 27, 2022
5. CallumECameron commented on Jun 6, 2022

   

   CallumECameron

   on Jun 6, 2022

   Author

   More actions

   Ah, okay, thank you. I have tried deriving from MockFileSystem and overriding the FileSystemWatcher property but I can't see any way to intercept calls to IMockFileDataAccessor to support the functionality of my file watcher mock (e.g. when a file is removed, the watcher will notify). I think I would need to reimplement MockFileSystem to add this behaviour unless you know of something else?
6. fgreinacher commented on Jun 23, 2022

   

   fgreinacher

   on Jun 23, 2022

   Contributor

   More actions

   Sorry @CallumECameron, I forgot to get back to this after my vacation.

   At the moment I see two options:

   1. Mock the behavior of the file system watcher to fire the expected events independently of the file system actions.
   2. (Similar to what you said): Have a custom IFileSystem that intercepts calls and triggers the expected events. There is a good example at Make the test library open for extension #597 (comment).

   Does that help?

   👍React with 👍1Reacted by Callum Cameron
7. CallumECameron commented on Jul 5, 2022

   

   CallumECameron

   on Jul 5, 2022

   Author

   More actions

   No problem, @fgreinacher, thanks for getting back to me. This helped, thank you.
8. zivarah commented on May 14, 2023

   

   zivarah

   on May 14, 2023

   Last edited by zivarah

   Contributor

   More actions

   @fgreinacher I am curious if there is a middle ground between trying to ship a fully functioning MockFileSystemWatcher and forcing the consumer to provide one just to allow their tests to run at all.

   For context: I have a class that accepts IFileSystem as an injected dependency. That code uses IFileSystemWatcher as well as various other IFileSystem APIs. I have two testing desires:

   1. Test APIs that are not reliant on the file system watching aspect at all
   2. Test behaviors that are triggered by the IFileSystemWatcher events

   But because we set up a file watcher at construction, the built-in MockFileSystem throws even for the APIs that don't use it.

   In order to test my non-watching behaviors, I have to provide some sort of IFileSystemFactory implementation. In order to test the IFileSystemWatcher event handlers, I'd obviously need to build that capability into my custom factory/watcher.

   The first piece is rather trivial, and I haven't gotten to the second piece yet.

   While I absolutely agree that we don't want the default behavior to be misleading/incomplete, it seems like we could provide a more useful opt-in option out of the box too.

   Would you be open to either of the below ideas?

   1. Ship a NoOpFileSystemWatcher that allows the dependent code to set up the file watcher and access any events/properties without any errors, but makes no attempts to actually trigger any events
   2. Ship a ManuallyTriggeredFileSystemWatcher that allows setup as above, but that also allows the test code to manually trigger specific events
      1. This avoids the need to deal with replicating exact file-watching behaviors while still providing an option for testing the event handlers

   I admittedly haven't attempted to actually develop either of these yet, but my gut instinct is that we'd be able to keep complexity fairly low. I'd be willing to take a stab at it if you are not opposed.
9. vbreuss commented on May 16, 2023

   

   vbreuss

   on May 16, 2023

   Member

   More actions

   @zivarah : I created an alternative MockFileSystem in Testably.Abstractions, that uses the same interface as System.IO.Abstractions and which implements a fully-functional FileSystemWatcher.
   
   You can directly use this mocked filesystem in your tests without having to change your production code.

   A very basic example test (deletion of a file) that illustrates the functionality would be:

   	[Fact]
   	public void EnableRaisingEvents_WhenDirectoryGetsDeleted_ShouldTriggerCorrectFileSystemEventArgs()
   	{
   		MockFileSystem fileSystem = new();
   		fileSystem.InitializeIn("base-directory")
   			.WithSubdirectory("foo");
   		FileSystemEventArgs? result = null;
   		ManualResetEventSlim ms = new();
   		using IFileSystemWatcher fileSystemWatcher =
   			fileSystem.FileSystemWatcher.New(".");
   		fileSystemWatcher.Deleted += (_, eventArgs) =>
   		{
   			result = eventArgs;
   			ms.Set();
   		};
   		fileSystemWatcher.NotifyFilter = NotifyFilters.DirectoryName;
   		fileSystemWatcher.EnableRaisingEvents = true;
   
   		fileSystem.Directory.Delete("foo");
   
   		ms.Wait(1000).Should().BeTrue();
   
   		result.Should().NotBeNull();
   		result!.ChangeType.Should().Be(WatcherChangeTypes.Deleted);
   		result.FullPath.Should().Be(fileSystem.Path.GetFullPath("foo"));
   	}
10. fgreinacher commented on May 20, 2023

    

    fgreinacher

    on May 20, 2023

    Contributor

    More actions

    Would you be open to either of the below ideas?

    @zivarah Yes, absolutely! Both options seem fine to me, as long as we keep them opt-in. Feel free to submit a PR for discussing how we can integrate this nicely!