Conseils sur les tests unitaires, la classe à tester dépend du port série Java

Question

Je travaille sur une application Java de grande taille. Il dispose déjà d'un vaste cadre existant pour gérer les pilotes de périphériques. J'ai besoin de créer un nouveau pilote de périphérique pour un périphérique qui se connecte à un port série via JavaComm. Les pilotes existants créent simplement le nouveau port série dans leurs méthodes configure(), puis créent de nouveaux flux d'entrée et de sortie à partir de l'objet port série, puis utilisent ces flux d'entrée et de sortie pour les communications de périphérique, mais sans tests unitaires. Je souhaite cependant que ma nouvelle classe soit testable à l'unité, mais je ne sais pas comment je pourrais le faire si elle devait s'intégrer à ce framework existant qui s'attend à ce que le port série, les flux d'entrée et de sortie soient configurés dans configure() méthode.

Des idées?

 

    public void configure() 
    { 
     super.configure(); 

     if (isEmulated()) { 
      return; 
     } 
     if (isFaulty()) {   
      if (isOutOfService()) { 
       ZBopNotificationManager.getInstance().add(
         new SystemNotice(SeverityCode.LEVEL3, getName(), getErrorMessage())); 
      } 
      return;   
     } 

     // ZP: 
     String portName = getSerialPort(); 
     // String portName = "COM1"; 
     try { 
      CommPortIdentifier id = CommPortIdentifier.getPortIdentifier(portName); 
      Trace.log(this, Trace.D, "Port name = " + id.getName()); 
      port = (SerialPort) id.open(getName(), 1000); 
     } catch (NoSuchPortException nspe) { 
      report(SeverityCode.LEVEL3, getName(), "Bar Code Scanner is not connected to " + portName + " port, or the port does not exist."); 
      return; 
     } catch (PortInUseException piue) { 
      report(SeverityCode.LEVEL3, getName(), portName + " port is already in-use by some other device. Reason: " + piue.getMessage()); 
      return; 
     } 

     try { 
      port.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 
     } catch (UnsupportedCommOperationException e) { 
      // this should not happen 
      port.close(); 
      report(SeverityCode.LEVEL2, getName(), portName + " port configuration failed: " + e); 
      return; 
     } 

     try { 
      in = port.getInputStream(); 
      out = port.getOutputStream(); 
     } catch (IOException ioe) { 
      port.close(); 
      report(SeverityCode.LEVEL3, getName(), portName + " port configuration failed: " + ioe.getMessage()); 
      return; 
     } 
meout(30); 

     // ... other init code omitted 
    } 

 

Answer 1

par les regards des choses, l'API javax.comm ne rend pas la vie facile pour les tests unitaires - il est grand sur les classes, et de la lumière sur les interfaces. Je suggère de créer des interfaces et des classes d'adaptateur pour chaque classe javax.comm que vous devez utiliser dans votre pilote. Votre code de pilote parlerait alors à ces interfaces, plutôt que directement à javax.comm. Vous n'avez probablement besoin que d'un sous-ensemble de l'API, et la définition de ces interfaces devrait vous aider à clarifier votre conception. Cela vous permettra d'utiliser des implémentations simulées de ces interfaces dans vos tests unitaires (par exemple JMock, Mockito, etc.). Votre test d'unité peut injecter ces mocks dans l'objet pilote.

En cas d'utilisation réelle, la méthode configure() du pilote peut instancier les classes de l'adaptateur plutôt que les mocks.

Answer 2

Si je vous ai bien compris, vous voulez tester devicedriver et non un module qui utilise le pilote de périphérique.

Est-il acceptable d'avoir un test d'intégration au lieu d'un test unidest? Si vous connectez le rxdata du port série avec le txdatapin et le rts avec le pin cts, alors le test d'intégration peut vérifier que tout ce qui est envoyé dans outputtream doit être reçu par le flux d'entrée.