On 07/05/16 11:10, Martin Byrenheid wrote: > Hello everyone, > > I've spend some time thinking about how to make it easier to test Freenet's > different subsystems, especially without having to instantiate the whole > Freenet Node class for almost every test. One possibly helpful idea that came > to my mind is to decouple classes by using a publish-subscribe mechanism, > where each instance can subscribe to events (e.g. received a new announcement > request) and publish other events together with corresponding data (e.g. the > message and the neighbor node where the request came from). This way, many > subsystems could then trigger methods in other subsystems without having to > know them directly and also might not need a reference to the Node class > anymore, making them much easier to test. > > I've integrated some examples within the NodeDispatcher-class and pushed it > into my Github repository [1]. Due to its rather high level of abstraction, > the publish-subscribe mechanism handles all attached data just as objects, > which is not nice regarding type safety. However, I haven't yet found a > better > solution since I don't have much experience with Java and I first want to > hear > your opinion about this approach.
Some people have talked about Mockito, though it means another dependency. Personally I find that objectionable unless a usable version is packaged in common linux distributions, for reasons of code integrity. It's not actually that hard to instantiate a node. My work on simulations does it, and so do the existing multi-node tests in freenet/node/simulator/. That code also involves bypassing the transport layer, bypassing the message layer, using a proxy NodeDispatcher to keep track of where messages go between nodes, and a subclass of RequestTracker. Also, you don't have to _start_ the node. The other approach is just to use more interfaces (I have done some of this)... Your events interface is a relatively extreme form of this, which is interesting, although I'm not sure if it's the right approach (it might be). Mockito has a big advantage in that we can just create a no-op Node or IPAddressDetector as needed, without needing to add lots more interfaces that only have one implementation at run-time. There is the more specific question of how much do we want NodeDispatcher to do anyway? Arguably a lot of its methods - even stuff like starting an announcement - are very similar, reading fields from a message, doing sanity checks etc. Perhaps it should unwrap the Message's rather than passing them elsewhere, to keep this sort of code all in one place? Some things could usefully be made static. The reason that more aren't is the need to simulate multiple nodes in a single JVM. However things like IPAddressDetector are, or should be, per-system not per-node.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
