jeudi 23 février 2023

Proper design of classes that call methods of stored objects

Say you have a node class and a graph class. nodes have a method, split() that uses its inner properties and returns new nodes. nodes are added to graphs which have a method splitWhen() which splits all nodes that fit certain criteria and stores the new nodes.

class Node {
  split() { }
}
class Graph {
  this.nodes = [];
  addNode(node) { }
  splitWhen(callback) { 
    // Call this.node[x].split() and store the returned nodes
  }
}

Testing splitWhen isn't straightforward since mocking node.split() to return new nodes, feels like too much mock implementation. At the same time, having graph call a node's method feels like there's room for improvement.

Is there a technique or pattern that does this type of stored inner object method calls in a more testable and maintainable way or is that not necessary?

A simple but indirect analogue would be calling built in prototype methods. Say instead of nodes, it's just an internal array property, and that graph.splitWhen() just uses Array.prototype.filter(). We wouldn't need to mock filter and we just test that splitWhen() is implemented correctly by asserting on the results.

Can we extend the same logic to node.split() since it's tested in the node class and not have to mock it?

Aucun commentaire:

Enregistrer un commentaire