On 29 March 2016 at 18:02, Sam Ruby <ru...@intertwingly.net> wrote: > On Tue, Mar 29, 2016 at 12:29 PM, sebb <seb...@gmail.com> wrote: >> For unit testing purposes it can be useful to be able to disable svn >> actions and replace them with a log message. > > FWIW, the board agenda tool handles this by creating test repositories: > > https://github.com/apache/whimsy/blob/master/www/board/agenda/Rakefile#L44 > https://github.com/apache/whimsy/blob/master/www/board/agenda/main.rb#L24
I see. However that relies on careful use to ensure that all svn repo URLs are changed. >> And for live running it can be useful to log the system commands that are >> run. >> >> It might therefore be useful to add some utility functions to >> encapsulate the system calls. > > Note that scripts that use wunderbar will capture the output and add > it to the "transcript" that is returned to the client: > > https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/builder.rb#L555 Yes, I noticed that. > An example of this was recently posted to a the (ASF confidential) board list: > > https://mail-search.apache.org/members/private-arch/board/201603.mbox/raw/%3CCAAS6=7gQSnsqMyCE4wmst7KH8HSgB=H=uxoqk4sxd+azwtk...@mail.gmail.com%3E/2 > Note that the wunderbar support will support parameter lists that are > arrays, and will NOT echo parameters that are in nested arrays. This > enables noise arguments (--no-auth-cache, --non-interactive), and > credentials (--username, --password) to be omitted from the log. This behaviour does not appear to be documented... >> WDYT? > > Things of general use (like logging of commands) can be put into > wunderbar, and doing so would minimize the need to modify existing > applications to take advantage of the feature. That being said, it > might be worth making opt-in, where an application makes a single call > to enable or disable logging of system commands. That would be fine by me. > While I like the idea of more logging, I'm less comfortable with > disabling svn actions in testing. My preference is to do testing with > dummy repositories over mocking out the function entirely. A potential problem with using dummy repos is that it is easy to overlook a repo and use the real one. Or just possibly to use a dummy when the real one should have been used. Whereas with all SVN calls using a single function, either the real ones are used or none - it should be pretty obvious if something has gone wrong. > - Sam Ruby
