On 11/5/10 9:21 PM, Eric Haszlakiewicz wrote:
On Fri, Nov 05, 2010 at 06:20:27PM +0200, Alan Barrett wrote:If the test expects cuf1;cuf1, and later somebody improves the curses library to emit "bc" or TAB instead, then the test would fail, but the actual change to the code would be an improvement, not a bug. I think everybody understands this, but some people draw the conclusion "therefore the tests should not be at this abstraction level", and other people draw the conclusion "therefore we will have to deal with updating the tests as the code changes".It seems to me that we need *both* a specification for what the final result should be, as well as the details of how the terminal gets to that state. If you know that the final result is identical, you can be more confident in updating the the other part of the test as needed.
Exactly what I was going to say.It seems to me that people are fighting here about two different approaches to test curses when both approaches seem perfectly valid and /not/ mutually exclusive.
Testing the screen contents should be seen as testing the interface of the library. This kind of test is excellent when it comes to refactoring/optimizing: you can be sure that any changes to the code did not break something obvious if the screen contents remain the same. These tests should not need to change when the library code is touched.
Testing for the specific sequence of characters emitted by curses serves a different purpose. It lets you ensure that the particular implementation is behaving exactly as you intended. These tests may need to change when the library code is touched.
Just my 2c.