#357: Enable meaningful testing of t/native_pbc/*.t
----------------------+-----------------------------------------------------
 Reporter:  doughera  |       Owner:     
     Type:  todo      |      Status:  new
 Priority:  normal    |   Milestone:  1.0
Component:  none      |     Version:     
 Severity:  medium    |    Keywords:     
     Lang:            |       Patch:     
 Platform:            |  
----------------------+-----------------------------------------------------

Comment(by jkeenan):

 Replying to [ticket:357 doughera]:

 I strongly agree with Andy Dougherty's comments.  My impression is that
 these tests don't stay fixed once we've fixed them, and they don't stay
 TODO-ed when we TODO them.  Now, I know that's not literally true, but if
 you don't stay on #parrot all day long, that's the impression you might
 get.

 > Version 0.9.1 was released with failing t/native_pbc/*.t tests.  If the
 tests are to

 [snip]

 >
 > 1.  The tests act differently in "DEVELOPING" versus released
 directories, meaning all the tests done in an svn-checkout -- even those
 done just prior to release -- weren't necessarily relevant.
 >

 We've long had the ability to write tests such that they respond one way
 if we're ''DEVELOPING'' and another way if we're not.  Parrot::Revision
 works in this way, so I wrote tests which take that into account.
 {{{
 t/configure/018-revision_to_cache.t
 t/configure/061-revision_from_cache.t
 t/configure/017-revision_from_cache.t
 }}}
 I suspect that the ''t/native_pbc/*.t'' tests could be adapted in the same
 way.


 > 2.  The release procedure is difficult in practice.  It is not easy, on
 short notice, to get developers with all the requisite different platforms
 to run the appropriate scripts, commit the appropriate files, and re-run
 all the appropriate tests.  Also, because of item 1, even running all the
 appropriate tests does not ensure that the tests will actually pass in the
 released version.
 >

 Agreed.

 > [snip]
 > What to do?
 >
 > First, if the tests are to be kept, they must be designed so that they
 can be meaningfully run well in advance of the release.

 See above for part of the solution.

 Thank you very much.[[BR]]
 kid51

-- 
Ticket URL: <https://trac.parrot.org/parrot/ticket/357#comment:1>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets

Reply via email to