You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ok - we have a slow implementation of the GraphClimber (no Reflection.Emit/Expressions here).
This allows us to play with the api (and apply changes to it), and also allows us to do a bit TDD: we can write integration tests for the SlowGraphClimber. After that, when we implement the real GraphClimber, we run the tests and find bugs.
Since GraphClimber can only be tested by integration tests, I suggest we write some simple processors and check that they behave correctly. Some processors include: finding all paths in an object with a null value, extracting all strings of an object, some simple serializer/deserializer and etc.
I'd like hear about other ideas for processors/tests.
The text was updated successfully, but these errors were encountered:
About the tests, Integration tests sound fine because it's nice to compare implementations (reflection vs expression/IL based GC). But I would like to TDD the expression/IL based GC.
Ok - we have a slow implementation of the GraphClimber (no Reflection.Emit/Expressions here).
This allows us to play with the api (and apply changes to it), and also allows us to do a bit TDD: we can write integration tests for the SlowGraphClimber. After that, when we implement the real GraphClimber, we run the tests and find bugs.
Since GraphClimber can only be tested by integration tests, I suggest we write some simple processors and check that they behave correctly. Some processors include: finding all paths in an object with a null value, extracting all strings of an object, some simple serializer/deserializer and etc.
I'd like hear about other ideas for processors/tests.
The text was updated successfully, but these errors were encountered: