#159 CoCo für Falsch Verbundene Connections#89
#159 CoCo für Falsch Verbundene Connections#89marcelgruen7-art wants to merge 10 commits intorelease/7.8.xfrom
Conversation
| SysMLv2Mill.addCollectionTypes(); | ||
| Log.clearFindings(); | ||
| } | ||
| /** |
There was a problem hiding this comment.
Entweder die Methode entfernen, oder die Sym-Files. Falls zweiteres, dann bietet es sich an die Methode mit "BeforeAll" zu mergen und die Sym-File nach target/ zu generieren
| * Ziel: Testen, dass CoCos auch ohne direkten Zugriff auf das AST funktionieren, | ||
| * wenn nur die SymbolTable zur Verfügung steht. | ||
| */ | ||
| public class SymbolTableCreationTest { |
There was a problem hiding this comment.
Die Klasse testet die CoCo und sollte entsprechend umbenannt werden
| var checker = new SysMLv2CoCoChecker(); | ||
| checker.addCoCo(new ParentSubConnectionCoCo()); | ||
| checker.checkAll(ast); | ||
| assertThat(Log.getFindings()).isEmpty(); //Correkt example |
There was a problem hiding this comment.
| assertThat(Log.getFindings()).isEmpty(); //Correkt example | |
| assertThat(Log.getFindings()).isEmpty(); // Correct example |
Ich würde eher den Test treffend benennen: testValidConnections()
| checker.addCoCo(new ParentSubConnectionCoCo()); | ||
| checker.checkAll(ast); | ||
| assertThat(Log.getFindings()).isEmpty(); //Correkt example | ||
| System.out.println(Log.getFindings()); |
There was a problem hiding this comment.
Keine Print-Statements
| System.out.println(Log.getFindings()); |
|
|
||
| import static org.assertj.core.api.Assertions.assertThat; | ||
|
|
||
| public class ParentComponentInputConnectionDirectionCoCoTest { |
There was a problem hiding this comment.
Es gibt also bereits einen Test zu der CoCo -> keine neuen Klassen erstellen sondern in die existierenden schreiben!
| import java.util.List; | ||
| import java.util.Optional; | ||
|
|
||
| /** |
There was a problem hiding this comment.
Kommentare nicht entfernen, höchstens updaten
| protected PortUsageSymbol resolvePortOfSubPart(ISysMLPartsScope scope, | ||
| String qname) { | ||
| // Split "a.out" into part "a" and port "out" | ||
|
|
There was a problem hiding this comment.
Unnötige Änderungen vermeiden
| } | ||
| } | ||
|
|
||
| /** |
There was a problem hiding this comment.
| /** | |
| /** |
| // Determine if endpoints reference subcomponents | ||
| boolean tgtIsSub = isSubcomponentEndpoint(tgtQName); | ||
| boolean srcIsSub = isSubcomponentEndpoint(srcQName); | ||
| boolean tgtIsSub = isSubcomp(tgtQName); |
There was a problem hiding this comment.
Brauchen wir diese ganzen Fälle wirklich, oder reicht es zu prüfen, dass beide Seiten der Connections den selben Typen, also die selbe PortDef, angeben, einmal normal und einmal invertiert (die SysML sagt "konjugiert", "~")? Falls beide Enden PortUsages sind, aber die PortDefs nicht passen könnte man noch die Attribute vergleichen, aber das würde ich erstmal auf den nächsten PR schieben.
| return portAttributeUsageAST.getModifier(); | ||
| } | ||
|
|
||
| protected boolean portIsInput(PortUsageSymbol symbol) { |
There was a problem hiding this comment.
Siehe oben, diese Methoden sind mir ein Dorn im Auge. Die scheinen eigentlich nur dazu da zu sein die Fehlermeldung anzupassen, der zugrundeliegende Check "sind die Enden kompatibel" braucht diese Information nicht
3 participants
Changelog
Changed