Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^2: Test driven development with Perl and vim

by gaal (Parson)
on Feb 28, 2005 at 20:17 UTC ( #435181=note: print w/ replies, xml ) Need Help??


in reply to Re: Test driven development with Perl and vim
in thread Test driven development with Perl and vim

What does :make buy you here? vim's makeprg just automates loading the error file, but that's taken care of in the Prove function. If you're going into the trouble of using make IMHO you may as well leave it for c development so that if you're writing a module with XS in it you get quickfix benefits for that.

Did you figure out that CompilerSet business going on in compiler/perl.vim? Maybe that's the key to localizing settigns that will help develop with more than one language at a time.


Comment on Re^2: Test driven development with Perl and vim
Select or Download Code
Re^3: Test driven development with Perl and vim
by dragonchild (Archbishop) on Feb 28, 2005 at 20:43 UTC
    Actually, as I discovered after posting, it's a lot easier to write a Compile() function that you get to control (like adding -Ilib) than depending on vim's make. So, I took that out. Plus, I found a few things better than BufNewFile and BufRead.

    This is how my .exrc snippet looks now:

    autocmd BufNewFile,BufRead *.p? so ~/.vim/perltest.vim autocmd BufEnter *.p? colors peachpuff autocmd BufNewFile,BufRead *.t so ~/.vim/perltest.vim autocmd BufEnter *.t colors blue

    And, I make a few changes to my perltest.vim

    The main changes are:

    • Addition of ,T allowing for make test TEST_VERBOSE=1
    • Addition of ,v allowing for compile of .t files. This entailed creating Compile()
    • Addition of -l flag to prove, keeping the vim editor in the same directory as the tags file.

    I'm still figuring out the various parameters. Heck, I've learned more about the vim settings in the last hour than I had in the 10+ years I've been using vi-based editors! :-)

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      Good point about taint mode. And -l can't hurt either, so I'm adding it too, though in all my new projects I've stopped with the (h2xs-originated, I think) legacy of putting everything under lib/. Well, actually if it's a web project I *do* use lib/ (and htdocs/ etc); but otherwise it's just snappier to use the main directory as the root for libraries.

      I'm not sure why you need the separate binding for compilation at all? I actually see it as a feature that Prove() does the Right Thing depending on whether the file is a test or not. (After all, if your test fails compile, quickfix will put you in the right place even if the compilation error happened when you tried to run the test.) Think of it as polymorphism at keybinding time :)

      Thanks for the comments!

      Update: Interesting thinko on my part, taking "verbose" for "taint". Well, I suppose they both tend to produce mode output than the regular checks :) I'm not convinced a verbose launch deserves a keybinding of its own — how often do you alternate? — maybe it's better to make both taint and verbose modes global options and keep the keys simple.

        If a failed test occurs when using ",t" then I want to re-run that specific testfile using ",T" so that I can see the helpful messages I put into each ok() statement. In Excel::Template, for example, I have almost 200 tests over 24 files and hope to be at 500 over 50+ before all is said and done. Each test file generally has between 4 and 20 tests, which is a manageable amount of output. 200 isn't.

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://435181]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (9)
As of 2014-12-27 02:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls