Skip to content
This repository has been archived by the owner on Jul 26, 2022. It is now read-only.

Brainstorm Architecture Testability

Gregor Trefs edited this page Jan 26, 2017 · 6 revisions

One of the major problems with Syncany is the architecture on the highest levels. The operations are not testable in an isolated way and I found this is preventing us from refactoring some critical pieces of infrastructure. In particular making Up/DownOperation memory efficient was (is?) a huge problem and I failed miserably in Cleanup.

I also got introduced to the concept of the Spring Framework, which has lead me to believe that this might be able to solve some of our problems. The following ideas have come to mind, in order of relevance:

  • Use Spring to do dependency injection/inversion of control. Use the decoupling induced by this process allow us to write unit (not integration) tests. Possibly useful: spring-test

  • Use spring-orm to decouple our hsql dependency. Also get rid of a lot of boilerplate code that we currently have and is partly untested.

  • Use spring-tx to do transaction management of local transactions during Operations. Not sure if possible: Also use it for transaction management on the remote.

Pim

To anyone who reads this, feel free to edit in feedback, or contact me about this plan.

-- Hi Pim,

I am just here to add my 2 cents.

  • Write down the goal of your refactoring effort and commit often.

  • Just introducing the Spring Framework does not help you. While Spring emphasizes some good concepts like DI and others, it also comes with the burden of an additional dependency and code which you don't own. Introducing Spring for the sake of making your code more testable is not a good reason.

  • Have a look at some legacy code refactoring techniques like Golden Master, Seams, Mocking, etc. A good resource for this is the book from Robert C. Martin "Working Effectively with Legacy Code".

Hope this helps a bit.

Best regards Gregor

--

Some comments through other channels:

  • It's better to fix the actual problem, for which Spring is not necessarily a solution itself.
  • Spring might be quite heavy. Alternative for DI: Google Juice, ORM: Hibernate

Pim

--

Have you considered using another persistence mechanism like jooq? It is not as heavy weight as an ORM. Further, you could use an EventStore to store the state of the application. But this could be a major rebuilt.

Gregor