For our frameworks, we don't tend to do much automated testing of the Mesos interface--instead, we construct the framework state, then "send it a message", since our callbacks take the state of the framework + the event as the argument. This way, we don't need to have mesos running, and we can trim away large amounts of code necessary to connect to mesos but unnecessary for the actual feature under test. We've also been experimenting with simulation testing by mocking out the mesos APIs. These techniques are mostly effective when you can pretend that the executors you're using don't communicate much, or when they're trivial to mock.
On Sun, Oct 12, 2014 at 9:42 AM, Dharmesh Kakadia <dhkaka...@gmail.com> wrote: > Hi, > > I am working on a tiny experimental framework for Mesos. I was wondering > what is the recommended way of writing testcases for framework testing. I > looked at the several existing frameworks, but its still not clear to me. I > understand that I might be able to test executor functionality in isolation > through normal test cases, but testing as a whole framework is what I am > unclear about. > > Suggestions? Is that a non-goal? How do other framework developers go > about it? > > Also, on the related note, is there a way to debug frameworks in better > way than sifting through logs? > > Thanks, > Dharmesh > > >
