Support SingleQueryCountHolder in SQLStatementCountValidator

[martin-tarjanyi]

Currently, SQLStatementCountValidator relies on the net.ttddyy.dsproxy.QueryCountHolder class which holds the query counts in a ThreadLocal field. However, datasource-proxy library also supports a different QueryCountStrategy called SingleQueryCountHolder which can count queries across multiple threads.

This strategy can be useful for example when testing against a web API where each request has its dedicated thread. In this case the default ThreadQueryCountHolder strategy is not appropriate as the request thread is not accessible from the test.

It would be nice if SQLStatementCountValidator could support the SingleQueryCountHolder strategy.

[vladmihalcea]

The SQLStatementCountValidator is meant to be used in data integration tests, and your data integration tests should not do any web request calls.

Bootstrapping an entire Spring Boot context just to test a single business method is not very efficient. It's worth testing the service method and its associated Repository calls.

Therefore, I don't see any reason why this utility should use SingleQueryCountHolder for testing. If you use it for statistics purposes at runtime, a Spring Actuator would be more useful.

However, it can surely be done via a configuration property that you can set via:

• Java System Property
• Environment Variable

The Configuration class already handles this logic.

However, the Configuration class should be moved from the type.util package to a util package that's shared between type, jdbc, and spring.

But, to make it backward compatible, the old Configuration class should extend this new one while declaring that it's now @Deprecated.

If you want to provide a Pull Request with these changes, then I could integrate this sooner rather than later.

[martin-tarjanyi]

If the application is thin enough (e.g. CRUD), having separate data integration tests are not always worth the effort in my opinion. It's easier to test the app as a whole.

Regarding the implementation of this feature, the tricky part is that the query count strategy also has to be set on the proxy datasource level, so changing SQLStatementCountValidator based on some propoerty wouldn't be enough unfortunately. Ofc, this could be documented along with the propery.

Anyway, as this util lib only provides an assertion layer on top of the proxy, it can be worked around rather easily. I just wondered if it's something tha could fit into this library.

[vladmihalcea]

If the application is thin enough (e.g. CRUD), having separate data integration tests are not always worth the effort in my opinion. It's easier to test the app as a whole.

Unless Spring Boot can start in 50 ms, then it will always be worth it. I have a very small Spring Boot app that uses this strategy. My integration tests run in 50-500 ms while bootstrapping Spring Boot would take 5-10 seconds. And this is a small Spring Boot app. So, until Spring native becomes mainstream, I don't see why anyone would want to bootstrap a Spring Boot app to test a single business use case.

Regarding the implementation of this feature, the tricky part is that the query count strategy also has to be set on the proxy datasource level, so changing SQLStatementCountValidator based on some propoerty wouldn't be enough unfortunately.

The solution will use the QueryCountStrategy that is implemented by both the ThreadLocal and the global strategies. Everything else will stay the same, as it's the case in datasource-proxy too.

Anyway, as this util lib only provides an assertion layer on top of the proxy, it can be worked around rather easily

It doesn't need to be a workaround. It can use the right strategy since datasource-proxy provides the QueryCountStrategy mechanism.

I just wondered if it's something tha could fit into this library.

The real test is whether someone will want to spend the time to implement it. If it's worth implementing it, then it's useful.

If no one took the time to implement it, then it's not worth it.

[martin-tarjanyi]

By workaround I meant that one can create SingleQueryCountHolder (for example as a Spring bean in tests), get the query count directly from there and assert it skipping using SQLStatementCountValidator. That seems to work fine. Currently, SQLStatementCountValidator doesn't provide too much benefit besides the nice error messages as far as I see. Of course, that might change in the future which can make implementing this issue worthwhile.