Nazri Ramliy wrote:
This is a reply of an almost 3-year old thread (but still relevant :)
On Fri, Jul 30, 2010 at 4:19 AM, Bram Moolenaar wrote:
Nazri Ramliy wrote:
What if we had some helper command that dumps how the
current screen look like so that it can be compared with
some "expected_du
This is a reply of an almost 3-year old thread (but still relevant :)
On Fri, Jul 30, 2010 at 4:19 AM, Bram Moolenaar wrote:
> Nazri Ramliy wrote:
>> What if we had some helper command that dumps how the
>> current screen look like so that it can be compared with
>> some "expected_dump.txt"?
>>
>
From: Tony Mechelynck, Fri, July 30, 2010 3:47 am
[...]
>
> There is already
>
> :runtime bugreport.vim
>
> in the plain-vanilla distribution, which collects a huge lot of
> information — in fact, usually too much for my health. ;-)
This is a lot of raw data about variables, mappings, abbrevi
On 28/07/10 23:46, Steve Hall wrote:
From: Dominique_Pellé, Wed, July 28, 2010 5:18 pm
1/ Human tests are certainly complementary with automated tests.
Having said that, I'm mostly in favor of adding more automated
tests (make test) or improving coverage of existing ones. I've
never looked at h
Nazri Ramliy wrote:
> On Thu, Jul 29, 2010 at 10:49 PM, Marc Weber wrote:
> >> Is anyone aware of anything like a terminal-emulator version of
> >> Selenium?
>
> What if we had some helper command that dumps how the
> current screen look like so that it can be compared with
> some "expected_dum
On Thu, Jul 29, 2010 at 10:49 PM, Marc Weber wrote:
>> Is anyone aware of anything like a terminal-emulator version of
>> Selenium?
What if we had some helper command that dumps how the
current screen look like so that it can be compared with
some "expected_dump.txt"?
Something along the lines o
> Is anyone aware of anything like a terminal-emulator version of
> Selenium?
cat the-testsuite.bin | vim ...
expect can record sessions. I don't know how easy it is to write test
cases that way. The problem is that you can't look at Vim while its
doing its work.
XTest could be another option -
On Wed, Jul 28, 2010 at 11:18:42PM +0200, Dominique Pellé wrote:
> 4/ Some bugs can also be found if we test Vim on different OS.
> How about keeping track of whether Vim successfully compiles and
> passes all tests on:
>
> - Linux (x86, x86_64, ARM, MIPS, ... )
> - Windows 95, 98, NT, 2000, XP, V
Hi Benjamin!
On Mi, 28 Jul 2010, Benjamin R. Haskell wrote:
>
> Is anyone aware of anything like a terminal-emulator version of
> Selenium? I've thought for several things like this that that would be
> incredibly useful.
>
> Brief summary of Selenium is that it's an automated web application
From: Dominique_Pellé, Wed, July 28, 2010 5:18 pm
>
> 1/ Human tests are certainly complementary with automated tests.
> Having said that, I'm mostly in favor of adding more automated
> tests (make test) or improving coverage of existing ones. I've
> never looked at how to write those tests myself,
Bram Moolenaar wrote:
> So far we have been testing by hoping for people to install Vim and use
> it. This does find problems related to daily use, but I suspect quite a
> few things are not yet used and bugs go unnoticed. Then when Vim 7.3 is
> released new features get used and bugs are uncove
Saluton Tony :)
Tony Mechelynck skribis:
> - Some of the new feature haven't yet got automated tests. They
> shouldbe identified, and tests written if possible.
Yes, any automation possible should be done. Given my low "kyu" in Vim,
I don't have the needed expertise to do this unfortunately.
>
On Wed, 28 Jul 2010, Bram Moolenaar wrote:
>
> So far we have been testing by hoping for people to install Vim and
> use it. This does find problems related to daily use, but I suspect
> quite a few things are not yet used and bugs go unnoticed. Then when
> Vim 7.3 is released new features g
On 28/07/10 17:07, Bram Moolenaar wrote:
Marc Weber wrote:
I also wonder if a shared document is the best way to do these things.
At least this allows multiple people at the same time making changes.
Most wiki's are not good at that.
If it is versioned then why not ? It can be accessed easil
Marc Weber wrote:
> > I also wonder if a shared document is the best way to do these things.
> > At least this allows multiple people at the same time making changes.
> > Most wiki's are not good at that.
>
> If it is versioned then why not ? It can be accessed easily by everyone.
> If its not ve
> I also wonder if a shared document is the best way to do these things.
> At least this allows multiple people at the same time making changes.
> Most wiki's are not good at that.
If it is versioned then why not ? It can be accessed easily by everyone.
If its not versioned I'd prefer git or mercur
So far we have been testing by hoping for people to install Vim and use
it. This does find problems related to daily use, but I suspect quite a
few things are not yet used and bugs go unnoticed. Then when Vim 7.3 is
released new features get used and bugs are uncovered. Too late!
It would be g
17 matches
Mail list logo
