When Unit Testing a Server, Why Not USE the Server?
Join the DZone community and get the full member experience.Join For Free
one of the most interesting aspects of build ravendb was that it opened up my mind to the way we can use the fundamental nature of the server to open up additional information about the server operations.
one thing that i noticed recently is that if i need to debug a test for ravendb, i often need to stop the current thread (the test thread) and then go to the server test instance to look at what is actually going on in there.
the fun part is that this is really nice, because i can go an inspect the running test instance, see what is going on, and then modify things to see how they affect the behavior, etc. the only problem is that this is actually quite complex to set up manually (stop on debugger, freeze the appropriate thread, resume run, inspect server – modify stuff there, stop on debugger, thaw thread, continue run, etc).
what occurred to me, however, is that i can codify this behavior, and end up with this:
this method will only operate while a debugger is attached, but it is going to save me a lot of time. once i am done, i need to delete the marker document:
this is especially important if you are running in memory mode, since the moment the test is over, the database is completely wiped out.
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
A React Frontend With Go/Gin/Gorm Backend in One Project
How To Use Pandas and Matplotlib To Perform EDA In Python
Scaling Site Reliability Engineering (SRE) Teams the Right Way
RBAC With API Gateway and Open Policy Agent (OPA)