Separate recording phase and test generation

almondtools / testrecorder

Create Test Fixtures from Runnable Java Code

http://testrecorder.amygdalum.net/

GNU Lesser General Public License v3.0

51 stars 5 forks source link

Separate recording phase and test generation #27

Closed almondtools closed 6 years ago

almondtools commented 7 years ago

I think about separating both phases:

recording and serialization
generating/deserialization

The result of the recording is a set of records (maybe configurable as files, db-records, ...)

There would be some advantages in such a new architecture:

failing test generators do not lead to discarding the test data
test generators will not consume memory concurring with serialization process
filtering/analyzing/transforming records can be developed incrementally
third party projects can use the serialized files for other purpose (instead of test generation)

The files cannot be strongly structured, since the serialization model is extendable (there may be more and more subtypes of serialized value)

The next task would be:

a wellfounded, queryable serialization format (supporting recursive structures)
a serializer for this format
a deserializer for this format
adjusting the documentation

almondtools commented 7 years ago

This new architecture should be applied after getting insights to the usage of testrecorder, so it is probably not coming in the next milestone

almondtools commented 7 years ago

Some further ideas that would benefit from the architecture change:

Building pipelines for recorded data:

with listeners reading the recorded data in serialized format
with filters, ruling out certain scenarios or duplicates
with generators/adaptors generating test code => needs research on conversion engines (e.g. Apache Camel)

Building databases for recorded data:

with database import for the recorded data in serialized format
with querys to select exactly those tests => needs research on NoSQL Stores (must also decide wether a piece of data is stored as graph or as blob with properties)

almondtools commented 7 years ago

Some thoughts for proceeding:

create a new SnapshotConsumer decorating the configured one, we shall call the new class SnapshotBroker
SnapshotBroker writes the Snapshot to the file system
SnapshotBroker rereads the Snapshot from the file system
SnapshotBroker delegates the Snapshot from the file system to the decorated consumer

Next, after all tests running again, we can write a new client only depending on the filesystem snapshot. The new SnapshotConsumer interface will probably not handle the ContextSnapshot object but probably the already serialized bytes (or a stream of these bytes).

almondtools commented 6 years ago

The tool evolving from this will be testrecorder-analyzer.

Currently it is a prototypic implementation that must grow with real projects. The next step would be to write a manual how to integrate it into testrecorder.