Timeline for Should I Have One Interface Per Class For Unit Testing?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 20, 2019 at 13:26 | comment | added | Etienne Charland | For FFmpegParser, I'm considering whether to remove the interface. It is possible that a future version of FFmpeg would have a slightly different output that would require different parsing. The interface would make such a scenario easy to resolve: flip to a different parser implementation based on the version. If I remove the interface, however, such a scenario would be a nightmare -- or I'd just update the class and it would break compatibility for users using an older FFmpeg. Thus, even for this case, keeping the interface is best IMO. | |
| Feb 20, 2019 at 12:41 | comment | added | Etienne Charland | I understand what you're saying, conceptually. In practice, however, for the library I'm working on right now, nearly all the code is part of the API, since I expose usage at 3 levels (working directly with the process, easy calling with preset args such as muxing and encoding, and accessing these presets via static methods for extra convenience). On top of that, 2 of the features are mostly only used by the calling application: UserInterfaceBase and TimeLeftCalculator. This leaves nothing as non-public interface. Perhaps I should leave it like that and revisit what you say for other code | |
| Feb 20, 2019 at 11:11 | comment | added | Etienne Charland | Could you take a look at this code I refactored? Small class library. Currently, all classes have an interface. Truth is, most classes can be used from the outside at some point; with the exception of FFmpegParser which could be left as a static class. Is there anything you would change to the project structure or interfaces? github.com/mysteryx93/FFmpeg.NET/tree/master/FFmpeg | |
| Feb 20, 2019 at 11:06 | comment | added | David Arno | And don't get hung up on the term "unit test", just write good quality, useful automated tests and leave the semantics to others. | |
| Feb 20, 2019 at 11:05 | comment | added | David Arno | "*It sounds like you're recommending to create interfaces only on code boundaries where the library is used from the outside -- but by doing so I have to unit test blocks of classes instead of individual classes. *". Spot on. You should only write tests for those boundary APIs; never try to write tests for the inner workings. They are implementation details that should be free to change in any way as long as they don't affect the boundary APIs. Trying to test such freely changing code will lead to brittle tests or restrictions on how you change. Neither is good. | |
| Feb 20, 2019 at 9:41 | comment | added | Etienne Charland | For now I'm refactoring a small stand-alone class library to practice all these concepts. What you're describing sounds like public vs private/internal members and classes. Is there something more to it? It sounds like you're recommending to create interfaces only on code boundaries where the library is used from the outside -- but by doing so I have to unit test blocks of classes instead of individual classes. | |
| Feb 20, 2019 at 9:09 | history | edited | candied_orange | CC BY-SA 4.0 | added 267 characters in body |
| Feb 20, 2019 at 9:03 | history | answered | candied_orange | CC BY-SA 4.0 |