Conversation
322899d to
13edc60
Compare
| let clear_error_override () = error_override := None | ||
| let get_last_binary () = !last_received_binary | ||
| let get_last_cmd () = !last_received_cmd | ||
| let get_resources () = !resources |
There was a problem hiding this comment.
this set of mutable global variables make me wonder:
- what is the goal of albatross mock?
- can you pass some state value across -- if needed? -- if that is not possible at all, then:
- could you construct a record with the respective fields and mutate them / have one global mutable?
I find this functionality at this stage rather confusing. I'd start with a smaller footprint, write some tests, and then slowly figure out what else needs testing and how to achieve it.
One possibility is to have one albatross which always replies with "success" (and if needed some hardcoded data), and another albatross always replies with "failure". This way, they don't need any state and you don't need to reimplement 50% of albatross (such as resource policies etc.).
There was a problem hiding this comment.
Albatross itself is a complex piece of software, and here in the mollymawk test suite you don't need to test albatross. The scope is to test mollymawk, so with the above proposal (one albatross replying success, the other failure) -- a test for destroying a unikernel will cover both paths (in unikernel.ml // unikernel_destroy there is after Albatross_state.query ... `Unikernel_destroy an Error `Msg _ case and an Ok _ case.
We shouldn't need an albatross daemon that tracks that you really created a unikernel with the same name beforehand.
This Pr attempts to create a mock albatross server which can send replies to commands submitted by mollymawk.
In essence, we open a socket, that mollymawk can connect to when the tests run.
Then we receive the TLS certificate from mollymawk and try to read from it what command is requested, we then match the command in
eval_commandand handle it in memory. Theeval_commandwill be extended to include block commands in other PR's and subsequently any commands we need to tests.