test: add integration package#544
Conversation
8bc4db7 to
5a17f1c
Compare
| s.StopAgent() | ||
| cmd := exec.Command("trace-agent", "-config", path) | ||
| s.log.Reset() | ||
| cmd.Stdout = s.log |
There was a problem hiding this comment.
Nice! We can even inspect logs ❤️
| return s.srv.Shutdown(ctx) | ||
| } | ||
|
|
||
| func (s *Runner) startBackend() error { |
There was a problem hiding this comment.
Nit: I would probably have a Backend abstraction encapsulating this and leave Runner just orchestrating (start/stop) both the agent and the Backend.
There was a problem hiding this comment.
These aspects we call "nits" are actually the ones I am most interested in when getting reviews. Structuring the code in the simplest, most decoupled and easy to understand (and test) way is what is most important to me. Your suggestion has also crossed my mind. I will explore this. It would even make sense to have the logic that starts/stops the agent as a separate unit.
p-lambert
left a comment
There was a problem hiding this comment.
This looks great! Left a couple of nits as separate comments (sorry about that 🤦♂️ )
71f1be2 to
a3fec37
Compare
|
@p-lambert I've separated out both the backend and the agent runner into separate more isolated components. I'd be curious to hear what you think if you can spare the time to take another look. |
d2aae3f to
e759ce2
Compare
913d715 to
f306982
Compare
That's exactly what I had in mind. I think now the abstractions have each a well defined set of responsibilities and the code is easier to follow (and hopefully to maintain!). Great job! |
43978d0 to
c94762d
Compare
c94762d to
862299d
Compare
Adds a package which allows running a fake backend and an agent with a given configuration. The runner exposes methods to send payloads to the agent and a channel to receive anything the agent outputs to the backend.
An example of how tests would be written, along with a first integration test can be seen in
test/suite/hostname_test.go