JUnit testing hampered by static methods
Posted: Fri Oct 11, 2013 4:05 pm
Hi,
while doing some debugging, I came across a good number of static methods for accessing objects stored in thread locals or request context, e.g. CartState.getCart(). That's a bad thing if you want to do JUnit-testing.
Are there any plans to replace static method calls e.g. by injecting singleton-scoped objects? This would definitely make https://github.com/BroadleafCommerce/Br ... t-coverage more realistic
By the way, is there a particular reason why the Cart is request-scoped? From what I understand, it is put into the request by the CartStateFilter, which seems to require a database query on each request (within CartStateRequestProcessor.process(WebRequest)). By putting the cart into the session, the database query would be required only once per session, which I'd find a performance improvement on first sight (requiring more memory in the JVM, though)
Regards,
Jörg
while doing some debugging, I came across a good number of static methods for accessing objects stored in thread locals or request context, e.g. CartState.getCart(). That's a bad thing if you want to do JUnit-testing.
Are there any plans to replace static method calls e.g. by injecting singleton-scoped objects? This would definitely make https://github.com/BroadleafCommerce/Br ... t-coverage more realistic

By the way, is there a particular reason why the Cart is request-scoped? From what I understand, it is put into the request by the CartStateFilter, which seems to require a database query on each request (within CartStateRequestProcessor.process(WebRequest)). By putting the cart into the session, the database query would be required only once per session, which I'd find a performance improvement on first sight (requiring more memory in the JVM, though)
Regards,
Jörg