Functional tests refactoring list

• Replace all usage of application code by own implementation

Test code must be independent from the application code. However, we widely use DTOs/Repositories from application in tests. The easiest way is just copy used classes to test package.

• Move methods from specs to models

At the moment, some of our test classes in specs have 'convenience' methods that are used only in this spec. It would be nice to move them to appropriate model in order to prevent code duplication (e.g. ConnectedDeviceSpec.verifyMeters() should be moved to Switch.getConnectedDeviceMetersDiscrepancies()).

• Add caching for topology parsing

At the moment, when we run single test during development, it calculates huge topology object (with switches, ISLs and, what is more important, paths). To avoid this, we can store cached topology object in file, to quickly read topology during development. File can contain serialized TopologyDefinition object and topology.yaml file's hash. If on start of the tests the hash or current topology.yaml is equal to the to the hash of cached topology, we can load TopologyDefinition object directly from serialized object instead of calculating paths and other once again.

• Replace helpers with business models

Currently we call northbound/kafka/other APIs directly from test specs or using so-called helpers. It would be nice to isolate specs from api calls like this:

• Get rid of test library package

/src-java/testing/test-library was isolated into library to serve both performance testing and functional testing. As long as performance testing is abandoned long time ago, we can get rid of the library and join it with functional-tests package. Profits: no possibility of circular dependency (functional tests -> test-lib -> functional tests); ability to use groovy in API part of the code as well.

• Rewrite java classes to groovy

Results from the point above.