thick nova
I am considering a microservices developer role and was wondering what some tools or strategies to debugging microservices are.
My friends told me to 'just do monolithic', but there has to be a way right? Not everyone uses monolithic and microservices are good job experience?
trail hornetBOT
⌛ This post has been reserved for your question.
Hey @thick nova! Please use
/closeor theClose Postbutton above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically closed after 300 minutes of inactivity.
TIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here.
dreamy geyser
unit tests
instead of debugging it, just get it working in the first place
pre-generate input json packages
and test that the output json matches ur expectations
for all combinations and permutations of input options
u dont even need mocking
median elk
That's one part of unit testing, seeing if your DTO apis match what you expect
There's also testing validation, business logic, data access
You basically described a Spring @JsonTest
trail hornetBOT
💤 Post marked as dormant
This post has been inactive for over 300 minutes, thus, it has been archived.
If your question was not answered yet, feel free to re-open this post or create a new one.
In case your post is not getting any attention, you can try to use/help ping.
Warning: abusing this will result in moderative actions taken against you.
thick nova
pre-generate input json packages
and test that the output json matches ur expect...
Can you explain why mocking isn't needed? With an example
dreamy geyser
if ur code is properly designed u should almost never need mocking
(which is one of the biggest reasons as to why TTD expects u to design tests first and then the code that applies)
as for why its not needed to test incoming and outgoing packets, thats because its at a program boundary ..... which means u MUST have an interface
which means u can use that interface to feed in ANYTHING u like without effecting the rest of ur program
when ur testing ur socket input and output and error handling etc, its reasonable to expect a slight need for some mocking
but the sockets most definitely must NOT be tightly coupled to the service logic
somewhere u should have something along the lines of:
public interface JSONQueryInput {
public void readJSON(String json);
}
public interface ServiceController implements
JSONQueryInput, JSONResultOutput, DBMSControl, ...... {
//....
}
which means that u just need to do something like
myMicroService.getController().readJSON(testJSONAddClient);
completely bypassing the socket which would normally automatically feed into that entry point
median elk
if ur code is properly designed u should almost never need mocking
(which is one...
this statement makes no sense
properly designed code has responsibilities nice and separated, and the whole point of unit tests is to fake what another object returns, to see if your code under tests reacts correctly to this
dreamy geyser
thats what i said .... if the code is nicely separated he doesnt need to mock a socket to give input into a separate code region