It should already be there. I had a single test in it before (a do-nothing
single test), for maybe 4 or 5 days.
On Fri, Oct 30, 2015 at 9:48 AM, Zachary Turner wrote:
> BTW, can you add EditlineTests.cpp to unittests/Editline/CMakeLists.txt?
> Currently this unittest only appears to be enabled
BTW, can you add EditlineTests.cpp to unittests/Editline/CMakeLists.txt?
Currently this unittest only appears to be enabled for the Xcode build (and
it might actually break the CMake build since CMake complains if there is a
cpp file that is not added to a target)
On Fri, Oct 30, 2015 at 9:43 AM T
> Should a unittest really have debug printfs?
Those are behind a define. edit line is inherently about converting input
to output, and when we layer in auto-tabbing, auto-completion, etc. it is
critical in test development to see how these develop. Every single touch
of this test is going to in
> What are all these setenv lines for?
libedit requires a TERM to know how to deal with the screen. We can't talk
to libedit if it can't figure out what kind of terminal it is working with.
> Another option is to use TEST_F instead of TEST(), and then declare a
class with Setup() and TearDown()
On Thu, Oct 29, 2015 at 7:57 PM Todd Fiala via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: tfiala
> Date: Thu Oct 29 21:54:52 2015
> New Revision: 251681
>
> URL: http://llvm.org/viewvc/llvm-project?rev=251681&view=rev
> Log:
> Added real editline tests.
>
> These are two simple t
Author: tfiala
Date: Thu Oct 29 21:54:52 2015
New Revision: 251681
URL: http://llvm.org/viewvc/llvm-project?rev=251681&view=rev
Log:
Added real editline tests.
These are two simple tests that make sure single line and
multiline content are processed and received by Editline.cpp.
Fancier tests to
