<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 17, 2015 at 10:39 AM <<a href="mailto:dawn@burble.org">dawn@burble.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Sep 17, 2015 at 05:20:14PM +0000, Zachary Turner wrote:<br>
> > > a) they should be explicitly marked as interface tests.<br>
> > What's the decorator for this?<br>
><br>
> There's not one currently.<br>
<br>
Will there be?<br></blockquote><div>Whenever someone adds one :)  If you want to start doing this, it should be fairly easy.  Even if the decorator doesn't do anything useful yet, you can just put it in and start putting it on interface tests if you want to start writing some.  I think earlier in the thread Jim agreed that it would be a good idea to separate command and api tests at the file system level as well.  So that's also something to think about if you plan to write some tests like this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> > > d) Results of these interface tests should also not be *verified* by the<br>
> > > use of self.expect, but itself through the API.  (Relying on the text to<br>
> > be<br>
> > > formatted a specific way is obviously problematic, as opposed to just<br>
> > > verifying the actual state of the debugger)<br>
> ><br>
> > How do you rely "on the text to be formatted a specific way"?<br>
><br>
> Quick example: One of the most common patterns in the test are to do some<br>
> things, print a backtrace, and run a regex against the output of the<br>
> backtrace.   I've found at least 3 different examples of how this causes<br>
> things to fail on Windows:<br>
<br>
Oh, I misunderstood your point.  You're saying the existing tests rely<br>
"on the text to be formatted a specific way".  Right.<br>
<br>
I was asking how you *could* make sure the output was formatted a<br>
specific way using the Python API.<br></blockquote><div><br></div><div>I'm actually not that convinced it's super useful.  Other people might disagree, but I'll let them chime in.  Personally I think it's much more useful to verify that typing a command with certain options affects the state of the debugger in the expected way.  Right now the way we verify this is by looking at the formatted output.  But another way (albeit much more work to get going) would be to have the command objects and the SB classes both be backed by the same classes that implement the commands (I admit I'm handwaving a little here)</div><div><br></div><div>This way your core functionality tests uses the python api and verifies the state of the debugger using the SB API, and your command tests simply process a command and get back some sort of configuration structure, and all you have to do is verify that the configuration structure is filled out correctly.  Since the core functionality tests already verified that the functionality works if passed an appropriate configuration structure, you don't need the command tests to actually do any work or manipulate the debugger.</div><div><br></div><div>Anyway, this is just a high level idea that probably needs refinement.  I'm mostly just brainstorming.</div></div></div>