Categories
Category results are hidden when using a custom project result order
0.0
Lookout
Lookout is a unit testing framework for Ruby┬╣ that puts your results in
focus. Tests (expectations) are written as follows
expect 2 do
1 + 1
end
expect ArgumentError do
Integer('1 + 1')
end
expect Array do
[1, 2, 3].select{ |i| i % 2 == 0 }
end
expect [2, 4, 6] do
[1, 2, 3].map{ |i| i * 2 }
end
Lookout is designed to encourage ΓÇô force, even ΓÇô unit testing best practices
such as
ΓÇó Setting up only one expectation per test
ΓÇó Not setting expectations on non-public APIs
ΓÇó Test isolation
This is done by
ΓÇó Only allowing one expectation to be set per test
ΓÇó Providing no (additional) way of accessing private state
ΓÇó Providing no setup and tear-down methods, nor a method of providing test
helpers
Other important points are
ΓÇó Putting the expected outcome of a test in focus with the steps of the
calculation of the actual result only as a secondary concern
ΓÇó A focus on code readability by providing no mechanism for describing an
expectation other than the code in the expectation itself
ΓÇó A unified syntax for setting up both state-based and behavior-based
expectations
The way Lookout works has been heavily influenced by expectations┬▓, by
{Jay Fields}┬│. The code base was once also heavily based on expectations,
based at Subversion {revision 76}⁴. A lot has happened since then and all of
the work past that revision are due to {Nikolai Weibull}⁵.
┬╣ Ruby: http://ruby-lang.org/
┬▓ Expectations: http://expectations.rubyforge.org/
┬│ Jay FieldsΓÇÖs blog: http://blog.jayfields.com/
⁴ Lookout revision 76:
https://github.com/now/lookout/commit/537bedf3e5b3eb4b31c066b3266f42964ac35ebe
⁵ Nikolai Weibull’s home page: http://disu.se/
§ Installation
Install Lookout with
% gem install lookout
§ Usage
Lookout allows you to set expectations on an objectΓÇÖs state or behavior.
WeΓÇÖll begin by looking at state expectations and then take a look at
expectations on behavior.
§ Expectations on State: Literals
An expectation can be made on the result of a computation:
expect 2 do
1 + 1
end
Most objects, in fact, have their state expectations checked by invoking
‹#==› on the expected value with the result as its argument.
Checking that a result is within a given range is also simple:
expect 0.099..0.101 do
0.4 - 0.3
end
Here, the more general ‹#===› is being used on the ‹Range›.
§ Regexps
‹Strings› of course match against ‹Strings›:
expect 'ab' do
'abc'[0..1]
end
but we can also match a ‹String› against a ‹Regexp›:
expect %r{a substring} do
'a string with a substring'
end
(Note the use of ‹%r{…}› to avoid warnings that will be generated when
Ruby parses ‹expect /…/›.)
§ Modules
Checking that the result includes a certain module is done by expecting the
‹Module›.
expect Enumerable do
[]
end
This, due to the nature of Ruby, of course also works for classes (as
they are also modules):
expect String do
'a string'
end
This doesn’t hinder us from expecting the actual ‹Module› itself:
expect Enumerable do
Enumerable
end
or the ‹Class›:
expect String do
String
end
for obvious reasons.
As you may have figured out yourself, this is accomplished by first
trying ‹#==› and, if it returns ‹false›, then trying ‹#===› on the
expected ‹Module›. This is also true of ‹Ranges› and ‹Regexps›.
§ Booleans
Truthfulness is expected with ‹true› and ‹false›:
expect true do
1
end
expect false do
nil
end
Results equaling ‹true› or ‹false› are slightly different:
expect TrueClass do
true
end
expect FalseClass do
false
end
The rationale for this is that you should only care if the result of a
computation evaluates to a value that Ruby considers to be either true or
false, not the exact literals ‹true› or ‹false›.
§ IO
Expecting output on an IO object is also common:
expect output("abc\ndef\n") do |io|
io.puts 'abc', 'def'
end
This can be used to capture the output of a formatter that takes an
output object as a parameter.
§ Warnings
Expecting warnings from code isnΓÇÖt very common, but should be done:
expect warning('this is your final one!') do
warn 'this is your final one!'
end
expect warning('this is your final one!') do
warn '%s:%d: warning: this is your final one!' % [__FILE__, __LINE__]
end
‹$VERBOSE› is set to ‹true› during the execution of the block, so you
donΓÇÖt need to do so yourself. If you have other code that depends on the
value of $VERBOSE, that can be done with ‹#with_verbose›
expect nil do
with_verbose nil do
$VERBOSE
end
end
§ Errors
You should always be expecting errors from ΓÇô and in, but thatΓÇÖs a
different story ΓÇô your code:
expect ArgumentError do
Integer('1 + 1')
end
Often, not only the type of the error, but its description, is important
to check:
expect StandardError.new('message') do
raise StandardError.new('message')
end
As with ‹Strings›, ‹Regexps› can be used to check the error description:
expect StandardError.new(/mess/) do
raise StandardError.new('message')
end
§ Queries Through Symbols
Symbols are generally matched against symbols, but as a special case,
symbols ending with ‹?› are seen as expectations on the result of query
methods on the result of the block, given that the method is of zero
arity and that the result isnΓÇÖt a Symbol itself. Simply expect a symbol
ending with ‹?›:
expect :empty? do
[]
end
To expect it’s negation, expect the same symbol beginning with ‹not_›:
expect :not_nil? do
[1, 2, 3]
end
This is the same as
expect true do
[].empty?
end
and
expect false do
[1, 2, 3].empty?
end
but provides much clearer failure messages. It also makes the
expectationΓÇÖs intent a lot clearer.
§ Queries By Proxy
ThereΓÇÖs also a way to make the expectations of query methods explicit by
invoking methods on the result of the block. For example, to check that
the even elements of the Array ‹[1, 2, 3]› include ‹1› you could write
expect result.to.include? 1 do
[1, 2, 3].reject{ |e| e.even? }
end
You could likewise check that the result doesnΓÇÖt include 2:
expect result.not.to.include? 2 do
[1, 2, 3].reject{ |e| e.even? }
end
This is the same as (and executes a little bit slower than) writing
expect false do
[1, 2, 3].reject{ |e| e.even? }.include? 2
end
but provides much clearer failure messages. Given that these two last
examples would fail, youΓÇÖd get a message saying ΓÇ£[1, 2, 3]#include?(2)ΓÇ¥
instead of the terser ΓÇ£trueΓëáfalseΓÇ¥. It also clearly separates the actual
expectation from the set-up.
The keyword for this kind of expectations is ‹result›. This may be
followed by any of the methods
• ‹#not›
• ‹#to›
• ‹#be›
• ‹#have›
or any other method you will want to call on the result. The methods
‹#to›, ‹#be›, and ‹#have› do nothing except improve readability. The
‹#not› method inverts the expectation.
§ Literal Literals
If you need to literally check against any of the types of objects
otherwise treated specially, that is, any instances of
• ‹Module›
• ‹Range›
• ‹Regexp›
• ‹Exception›
• ‹Symbol›, given that it ends with ‹?›
you can do so by wrapping it in ‹literal(…)›:
expect literal(:empty?) do
:empty?
end
You almost never need to do this, as, for all but symbols, instances will
match accordingly as well.
§ Expectations on Behavior
We expect our objects to be on their best behavior. Lookout allows you
to make sure that they are.
Reception expectations let us verify that a method is called in the way
that we expect it to be:
expect mock.to.receive.to_str(without_arguments){ '123' } do |o|
o.to_str
end
Here, ‹#mock› creates a mock object, an object that doesn’t respond to
anything unless you tell it to. We tell it to expect to receive a call
to ‹#to_str› without arguments and have ‹#to_str› return ‹'123'› when
called. The mock object is then passed in to the block so that the
expectations placed upon it can be fulfilled.
Sometimes we only want to make sure that a method is called in the way
that we expect it to be, but we donΓÇÖt care if any other methods are
called on the object. A stub object, created with ‹#stub›, expects any
method and returns a stub object that, again, expects any method, and
thus fits the bill.
expect stub.to.receive.to_str(without_arguments){ '123' } do |o|
o.to_str if o.convertable?
end
You donΓÇÖt have to use a mock object to verify that a method is called:
expect Object.to.receive.name do
Object.name
end
As you have figured out by now, the expected method call is set up by
calling ‹#receive› after ‹#to›. ‹#Receive› is followed by a call to the
method to expect with any expected arguments. The body of the expected
method can be given as the block to the method. Finally, an expected
invocation count may follow the method. LetΓÇÖs look at this formal
specification in more detail.
The expected method arguments may be given in a variety of ways. LetΓÇÖs
introduce them by giving some examples:
expect mock.to.receive.a do |m|
m.a
end
Here, the method ‹#a› must be called with any number of arguments. It
may be called any number of times, but it must be called at least once.
If a method must receive exactly one argument, you can use ‹Object›, as
the same matching rules apply for arguments as they do for state
expectations:
expect mock.to.receive.a(Object) do |m|
m.a 0
end
If a method must receive a specific argument, you can use that argument:
expect mock.to.receive.a(1..2) do |m|
m.a 1
end
Again, the same matching rules apply for arguments as they do for state
expectations, so the previous example expects a call to ‹#a› with 1, 2,
or the Range 1..2 as an argument on ‹m›.
If a method must be invoked without any arguments you can use
‹without_arguments›:
expect mock.to.receive.a(without_arguments) do |m|
m.a
end
You can of course use both ‹Object› and actual arguments:
expect mock.to.receive.a(Object, 2, Object) do |m|
m.a nil, 2, '3'
end
The body of the expected method may be given as the block. Here, calling
‹#a› on ‹m› will give the result ‹1›:
expect mock.to.receive.a{ 1 } do |m|
raise 'not 1' unless m.a == 1
end
If no body has been given, the result will be a stub object.
To take a block, grab a block parameter and ‹#call› it:
expect mock.to.receive.a{ |&b| b.call(1) } do |m|
j = 0
m.a{ |i| j = i }
raise 'not 1' unless j == 1
end
To simulate an ‹#each›-like method, ‹#call› the block several times.
Invocation count expectations can be set if the default expectation of
ΓÇ£at least onceΓÇ¥ isnΓÇÖt good enough. The following expectations are
possible
• ‹#at_most_once›
• ‹#once›
• ‹#at_least_once›
• ‹#twice›
And, for a given ‹N›,
• ‹#at_most(N)›
• ‹#exactly(N)›
• ‹#at_least(N)›
§ Utilities: Stubs
Method stubs are another useful thing to have in a unit testing
framework. Sometimes you need to override a method that does something a
test shouldnΓÇÖt do, like access and alter bank accounts. We can override
– stub out – a method by using the ‹#stub› method. Let’s assume that we
have an ‹Account› class that has two methods, ‹#slips› and ‹#total›.
‹#Slips› retrieves the bank slips that keep track of your deposits to the
‹Account› from a database. ‹#Total› sums the ‹#slips›. In the following
test we want to make sure that ‹#total› does what it should do without
accessing the database. We therefore stub out ‹#slips› and make it
return something that we can easily control.
expect 6 do |m|
stub(Class.new{
def slips
raise 'database not available'
end
def total
slips.reduce(0){ |m, n| m.to_i + n.to_i }
end
}.new, :slips => [1, 2, 3]){ |account| account.total }
end
To make it easy to create objects with a set of stubbed methods thereΓÇÖs
also a convenience method:
expect 3 do
s = stub(:a => 1, :b => 2)
s.a + s.b
end
This short-hand notation can also be used for the expected value:
expect stub(:a => 1, :b => 2).to.receive.a do |o|
o.a + o.b
end
and also works for mock objects:
expect mock(:a => 2, :b => 2).to.receive.a do |o|
o.a + o.b
end
Blocks are also allowed when defining stub methods:
expect 3 do
s = stub(:a => proc{ |a, b| a + b })
s.a(1, 2)
end
If need be, we can stub out a specific method on an object:
expect 'def' do
stub('abc', :to_str => 'def'){ |a| a.to_str }
end
The stub is active during the execution of the block.
§ Overriding Constants
Sometimes you need to override the value of a constant during the
execution of some code. Use ‹#with_const› to do just that:
expect 'hello' do
with_const 'A::B::C', 'hello' do
A::B::C
end
end
Here, the constant ‹A::B::C› is set to ‹'hello'› during the execution of
the block. None of the constants ‹A›, ‹B›, and ‹C› need to exist for
this to work. If a constant doesnΓÇÖt exist itΓÇÖs created and set to a new,
empty, ‹Module›. The value of ‹A::B::C›, if any, is restored after the
block returns and any constants that didnΓÇÖt previously exist are removed.
§ Overriding Environment Variables
Another thing you often need to control in your tests is the value of
environment variables. Depending on such global values is, of course,
not a good practice, but is often unavoidable when working with external
libraries. ‹#With_env› allows you to override the value of environment
variables during the execution of a block by giving it a ‹Hash› of
key/value pairs where the key is the name of the environment variable and
the value is the value that it should have during the execution of that
block:
expect 'hello' do
with_env 'INTRO' => 'hello' do
ENV['INTRO']
end
end
Any overridden values are restored and any keys that werenΓÇÖt previously a
part of the environment are removed when the block returns.
§ Overriding Globals
You may also want to override the value of a global temporarily:
expect 'hello' do
with_global :$stdout, StringIO.new do
print 'hello'
$stdout.string
end
end
You thus provide the name of the global and a value that it should take
during the execution of a block of code. The block gets passed the
overridden value, should you need it:
expect true do
with_global :$stdout, StringIO.new do |overridden|
$stdout != overridden
end
end
§ Integration
Lookout can be used from Rake┬╣. Simply install Lookout-Rake┬▓:
% gem install lookout-rake
and add the following code to your Rakefile
require 'lookout-rake-3.0'
Lookout::Rake::Tasks::Test.new
Make sure to read up on using Lookout-Rake for further benefits and
customization.
┬╣ Read more about Rake at http://rake.rubyforge.org/
┬▓ Get information on Lookout-Rake at http://disu.se/software/lookout-rake/
§ API
Lookout comes with an API┬╣ that letΓÇÖs you create things such as new
expected values, difference reports for your types, and so on.
┬╣ See http://disu.se/software/lookout/api/
§ Interface Design
The default output of Lookout can Spartanly be described as Spartan. If no
errors or failures occur, no output is generated. This is unconventional,
as unit testing frameworks tend to dump a lot of information on the user,
concerning things such as progress, test count summaries, and flamboyantly
colored text telling you that your tests passed. None of this output is
needed. Your tests should run fast enough to not require progress reports.
The lack of output provides you with the same amount of information as
reporting success. Test count summaries are only useful if youΓÇÖre worried
that your tests arenΓÇÖt being run, but if you worry about that, then
providing such output doesnΓÇÖt really help. Testing your tests requires
something beyond reporting some arbitrary count that you would have to
verify by hand anyway.
When errors or failures do occur, however, the relevant information is
output in a format that can easily be parsed by an ‹'errorformat'› for Vim
or with {Compilation Mode}┬╣ for Emacs┬▓. Diffs are generated for Strings,
Arrays, Hashes, and I/O.
┬╣ Read up on Compilation mode for Emacs at http://www.emacswiki.org/emacs/CompilationMode
┬▓ Visit The GNU FoundationΓÇÖs EmacsΓÇÖ software page at http://www.gnu.org/software/emacs/
§ External Design
LetΓÇÖs now look at some of the points made in the introduction in greater
detail.
Lookout only allows you to set one expectation per test. If youΓÇÖre testing
behavior with a reception expectation, then only one method-invocation
expectation can be set. If youΓÇÖre testing state, then only one result can
be verified. It may seem like this would cause unnecessary duplication
between tests. While this is certainly a possibility, when you actually
begin to try to avoid such duplication you find that you often do so by
improving your interfaces. This kind of restriction tends to encourage the
use of value objects, which are easy to test, and more focused objects,
which require simpler tests, as they have less behavior to test, per
method. By keeping your interfaces focused youΓÇÖre also keeping your tests
focused.
Keeping your tests focused improves, in itself, test isolation, but letΓÇÖs
look at something that hinders it: setup and tear-down methods. Most unit
testing frameworks encourage test fragmentation by providing setup and
tear-down methods.
Setup methods create objects and, perhaps, just their behavior for a set of
tests. This means that you have to look in two places to figure out whatΓÇÖs
being done in a test. This may work fine for few methods with simple
set-ups, but makes things complicated when the number of tests increases
and the set-up is complex. Often, each test further adjusts the previously
set-up object before performing any verifications, further complicating the
process of figuring out what state an object has in a given test.
Tear-down methods clean up after tests, perhaps by removing records from a
database or deleting files from the file-system.
The duplication that setup methods and tear-down methods hope to remove is
better avoided by improving your interfaces. This can be done by providing
better set-up methods for your objects and using idioms such as {Resource
Acquisition Is Initialization}┬╣ for guaranteed clean-up, test or no test.
By not using setup and tear-down methods we keep everything pertinent to a
test in the test itself, thus improving test isolation. (You also wonΓÇÖt
{slow down your tests}┬▓ by keeping unnecessary state.)
Most unit test frameworks also allow you to create arbitrary test helper
methods. Lookout doesnΓÇÖt. The same rationale as that that has been
crystallized in the preceding paragraphs applies. If you need helpers
youΓÇÖre interface isnΓÇÖt good enough. It really is as simple as that.
To clarify: thereΓÇÖs nothing inherently wrong with test helper methods, but
they should be general enough that they reside in their own library. The
support for mocks in Lookout is provided through a set of test helper
methods that make it easier to create mocks than it would have been without
them. Lookout-rack┬│ is another example of a library providing test helper
methods (well, one method, actually) that are very useful in testing web
applications that use Rack⁴.
A final point at which some unit test frameworks try to fragment tests
further is documentation. These frameworks provide ways of describing the
whats and hows of whatΓÇÖs being tested, the rationale being that this will
provide documentation of both the test and the code being tested.
Describing how a stack data structure is meant to work is a common example.
A stack is, however, a rather simple data structure, so such a description
provides little, if any, additional information that canΓÇÖt be extracted
from the implementation and its tests themselves. The implementation and
its tests is, in fact, its own best documentation. Taking the points made
in the previous paragraphs into account, we should already have simple,
self-describing, interfaces that have easily understood tests associated
with them. Rationales for the use of a given data structure or
system-design design documentation is better suited in separate
documentation focused at describing exactly those issues.
┬╣ Read the Wikipedia entry for Resource Acquisition Is Initialization at
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
┬▓ Read how 37signals had problems with slow Test::Unit tests at
http://37signals.com/svn/posts/2742-the-road-to-faster-tests/
┬│ Visit the Lookout-rack home page at
http://disu.se/software/lookout-rack/
⁴ Visit the Rack Rubyforge project page at
http://rack.rubyforge.org/
§ Internal Design
The internal design of Lookout has had a couple of goals.
ΓÇó As few external dependencies as possible
ΓÇó As few internal dependencies as possible
ΓÇó Internal extensibility provides external extensibility
ΓÇó As fast load times as possible
ΓÇó As high a ratio of value objects to mutable objects as possible
ΓÇó Each object must have a simple, obvious name
ΓÇó Use mix-ins, not inheritance for shared behavior
ΓÇó As few responsibilities per object as possible
ΓÇó Optimizing for speed can only be done when you have all the facts
§ External Dependencies
Lookout used to depend on Mocha for mocks and stubs. While benchmarking I
noticed that a method in Mocha was taking up more than 300 percent of the
runtime. It turned out that MochaΓÇÖs method for cleaning up back-traces
generated when a mock failed was doing something incredibly stupid:
backtrace.reject{ |l| Regexp.new(@lib).match(File.expand_path(l)) }
Here ‹@lib› is a ‹String› containing the path to the lib sub-directory in
the Mocha installation directory. I reported it, provided a patch five
days later, then waited. Nothing happened. {254 days later}┬╣, according
to {Wolfram Alpha}┬▓, half of my patch was, apparently ΓÇô I say ΓÇ£apparentlyΓÇ¥,
as I received no notification ΓÇô applied. By that time I had replaced the
whole mocking-and-stubbing subsystem and dropped the dependency.
Many Ruby developers claim that Ruby and its gems are too fast-moving for
normal package-managing systems to keep up. This is testament to the fact
that this isnΓÇÖt the case and that the real problem is instead related to
sloppy practices.
Please note that I donΓÇÖt want to single out the Mocha library nor its
developers. I only want to provide an example where relying on external
dependencies can be ΓÇ£considered harmfulΓÇ¥.
┬╣ See the Wolfram Alpha calculation at http://www.wolframalpha.com/input/?i=days+between+march+17%2C+2010+and+november+26%2C+2010
┬▓ Check out the Wolfram Alpha computational knowledge engine at http://www.wolframalpha.com/
§ Internal Dependencies
Lookout has been designed so as to keep each subsystem independent of any
other. The diff subsystem is, for example, completely decoupled from any
other part of the system as a whole and could be moved into its own library
at a time where that would be of interest to anyone. WhatΓÇÖs perhaps more
interesting is that the diff subsystem is itself very modular. The data
passes through a set of filters that depends on what kind of diff has been
requested, each filter yielding modified data as it receives it. If you
want to read some rather functional Ruby I can highly recommend looking at
the code in the ‹lib/lookout/diff› directory.
This lookout on the design of the library also makes it easy to extend
Lookout. Lookout-rack was, for example, written in about four hours and
about 5 of those 240 minutes were spent on setting up the interface between
the two.
§ Optimizing For Speed
The following paragraph is perhaps a bit personal, but might be interesting
nonetheless.
IΓÇÖve always worried about speed. The original Expectations library used
‹extend› a lot to add new behavior to objects. Expectations, for example,
used to hold the result of their execution (what we now term ΓÇ£evaluationΓÇ¥)
by being extended by a module representing success, failure, or error. For
the longest time I used this same method, worrying about the increased
performance cost that creating new objects for results would incur. I
finally came to a point where I felt that the code was so simple and clean
that rewriting this part of the code for a benchmark wouldnΓÇÖt take more
than perhaps ten minutes. Well, ten minutes later I had my results and
they confirmed that creating new objects wasnΓÇÖt harming performance. I was
very pleased.
§ Naming
I hate low lines (underscores). I try to avoid them in method names and I
always avoid them in file names. Since the current ΓÇ£best practiceΓÇ¥ in the
Ruby community is to put ‹BeginEndStorage› in a file called
‹begin_end_storage.rb›, I only name constants using a single noun. This
has had the added benefit that classes seem to have acquired less behavior,
as using a single noun doesnΓÇÖt allow you to tack on additional behavior
without questioning if itΓÇÖs really appropriate to do so, given the rather
limited range of interpretation for that noun. It also seems to encourage
the creation of value objects, as something named ‹Range› feels a lot more
like a value than ‹BeginEndStorage›. (To reach object-oriented-programming
Nirvana you must achieve complete value.)
§ News
§ 3.0.0
The ‹xml› expectation has been dropped. It wasn’t documented, didn’t
suit very many use cases, and can be better implemented by an external
library.
The ‹arg› argument matcher for mock method arguments has been removed, as
it didnΓÇÖt provide any benefit over using Object.
The ‹#yield› and ‹#each› methods on stub and mock methods have been
removed. They were slightly weird and their use case can be implemented
using block parameters instead.
The ‹stub› method inside ‹expect› blocks now stubs out the methods during
the execution of a provided block instead of during the execution of the
whole except block.
When a mock method is called too many times, this is reported
immediately, with a full backtrace. This makes it easier to pin down
whatΓÇÖs wrong with the code.
Query expectations were added.
Explicit query expectations were added.
Fluent boolean expectations, for example, ‹expect nil.to.be.nil?› have
been replaced by query expectations (‹expect :nil? do nil end›) and
explicit query expectations (‹expect result.to.be.nil? do nil end›).
This was done to discourage creating objects as the expected value and
creating objects that change during the course of the test.
The ‹literal› expectation was added.
Equality (‹#==›) is now checked before “caseity” (‹#===›) for modules,
ranges, and regular expressions to match the documentation.
§ Financing
Currently, most of my time is spent at my day job and in my rather busy
private life. Please motivate me to spend time on this piece of software
by donating some of your money to this project. Yeah, I realize that
requesting money to develop software is a bit, well, capitalistic of me.
But please realize that I live in a capitalistic society and I need money
to have other people give me the things that I need to continue living
under the rules of said society. So, if you feel that this piece of
software has helped you out enough to warrant a reward, please PayPal a
donation to now@disu.se┬╣. Thanks! Your support wonΓÇÖt go unnoticed!
┬╣ Send a donation:
https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now%40disu%2ese&item_name=Lookout
§ Reporting Bugs
Please report any bugs that you encounter to the {issue tracker}┬╣.
┬╣ See https://github.com/now/lookout/issues
§ Contributors
Contributors to the original expectations codebase are mentioned there. We
hope no one on that list feels left out of this list. Please
{let us know}┬╣ if you do.
ΓÇó Nikolai Weibull
┬╣ Add an issue to the Lookout issue tracker at https://github.com/now/lookout/issues
§ Licensing
Lookout is free software: you may redistribute it and/or modify it under
the terms of the {GNU Lesser General Public License, version 3}┬╣ or later┬▓,
as published by the {Free Software Foundation}┬│.
┬╣ See http://disu.se/licenses/lgpl-3.0/
┬▓ See http://gnu.org/licenses/
┬│ See http://fsf.org/
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.0
Inventory
Inventory keeps track of the contents of your Ruby¹ projects. Such an
inventory can be used to load the project, create gem specifications and
gems, run unit tests, compile extensions, and verify that the project’s
content is what you think it is.
¹ See http://ruby-lang.org/
§ Usage
Let’s begin by discussing the project structure that Inventory expects you
to use. It’s pretty much exactly the same as the standard Ruby project
structure¹:
├── README
├── Rakefile
├── lib
│ ├── foo-1.0
│ │ ├── bar.rb
│ │ └── version.rb
│ └── foo-1.0.rb
└── test
└── unit
├── foo-1.0
│ ├── bar.rb
│ └── version.rb
└── foo-1.0.rb
Here you see a simplified version of a project called “Foo”’s project
structure. The only real difference from the standard is that the main
entry point into the library is named “foo-1.0.rb” instead of “foo.rb” and
that the root sub-directory of “lib” is similarly named “foo-1.0” instead
of “foo”. The difference is the inclusion of the API version. This must
be the major version of the project followed by a constant “.0”. The
reason for this is that it allows concurrent installations of different
major versions of the project and means that the wrong version will never
accidentally be loaded with require.
There’s a bigger difference in the content of the files.
‹Lib/foo-1.0/version.rb› will contain our inventory instead of a String:
require 'inventory-1.0'
class Foo
Version = Foo.new(1, 4, 0){
authors{
author 'A. U. Thor', 'a.u.thor@example.org'
}
homepage 'http://example.org/'
licenses{
license 'LGPLv3+',
'GNU Lesser General Public License, version 3 or later',
'http://www.gnu.org/licenses/'
}
def dependencies
super + Dependencies.new{
development 'baz', 1, 3, 0
runtime 'goo', 2, 0, 0
optional 'roo-loo', 3, 0, 0, :feature => 'roo-loo'
}
end
def package_libs
%w[bar.rb]
end
}
end
We’re introducing quite a few concepts at once, and we’ll look into each in
greater detail, but we begin by setting the ‹Version› constant to a new
instance of an Inventory with major, minor, and patch version atoms 1, 4,
and 0. Then we add a couple of dependencies and list the library files
that are included in this project.
The version numbers shouldn’t come as a surprise. These track the version
of the API that we’re shipping using {semantic versioning}². They also
allow the Inventory#to_s method to act as if you’d defined Version as
‹'1.4.0'›.
Next follows information about the authors of the project, the project’s
homepage, and the project’s licenses. Each author has a name and an email
address. The homepage is simply a string URL. Licenses have an
abbreviation, a name, and a URL where the license text can be found.
We then extend the definition of ‹dependencies› by adding another set of
dependencies to ‹super›. ‹Super› includes a dependency on the version of
the inventory project that’s being used with this project, so you’ll never
have to list that yourself. The other three dependencies are all of
different kinds: development, runtime, and optional. A development
dependency is one that’s required while developing the project, for
example, a unit-testing framework, a documentation generator, and so on.
Runtime dependencies are requirements of the project to be able to run,
both during development and when installed. Finally, optional dependencies
are runtime dependencies that may or may not be required during execution.
The difference between runtime and optional is that the inventory won’t try
to automatically load an optional dependency, instead leaving that up to
you to do when and if it becomes necessary. By that logic, runtime
dependencies will be automatically loaded, which is a good reason for
having dependency information available at runtime.
The version numbers of dependencies also use semantic versioning, but note
that the patch atom is ignored unless the major atom is 0. You should
always only depend on the major and minor atoms.
As mentioned, runtime dependencies will be automatically loaded and the
feature they try to load is based on the name of the dependency with a
“-X.0” tacked on the end, where ‘X’ is the major version of the dependency.
Sometimes, this isn’t correct, in which case the :feature option may be
given to specify the name of the feature.
You may also override other parts of a dependency by passing in a block to
the dependency, much like we’re doing for inventories.
The rest of an inventory will list the various files included in the
project. This project only consists of one additional file to those that
an inventory automatically include (Rakefile, README, the main entry point,
and the version.rb file that defines the inventory itself), namely the
library file ‹bar.rb›. Library files will be loaded automatically when the
main entry point file loads the inventory. Library files that shouldn’t be
loaded may be listed under a different heading, namely “additional_libs”.
Both these sets of files will be used to generate a list of unit test files
automatically, so each library file will have a corresponding unit test
file in the inventory. We’ll discuss the different headings of an
inventory in more detail later on.
Now that we’ve written our inventory, let’s set it up so that it’s content
gets loaded when our main entry point gets loaded. We add the following
piece of code to ‹lib/foo-1.0.rb›:
module Foo
load File.expand_path('../foo-1.0/version.rb', __FILE__)
Version.load
end
That’s all there’s to it.
The inventory can also be used to great effect from a Rakefile using a
separate project called Inventory-Rake³. Using it’ll give us tasks for
cleaning up our project, compiling extensions, installing dependencies,
installing and uninstalling the project itself, and creating and pushing
distribution files to distribution points.
require 'inventory-rake-1.0'
load File.expand_path('../lib/foo-1.0/version.rb', __FILE__)
Inventory::Rake::Tasks.define Foo::Version
Inventory::Rake::Tasks.unless_installing_dependencies do
require 'lookout-rake-3.0'
Lookout::Rake::Tasks::Test.new
end
It’s ‹Inventory::Rake::Tasks.define› that does the heavy lifting. It takes
our inventory and sets up the tasks mentioned above.
As we want to be able to use our Rakefile to install our dependencies for
us, the rest of the Rakefile is inside the conditional
#unless_installing_dependencies, which, as the name certainly implies,
executes its block unless the task being run is the one that installs our
dependencies. This becomes relevant when we set up Travis⁴ integration
next. The only conditional set-up we do in our Rakefile is creating our
test task via Lookout-Rake⁵, which also uses our inventory to find the unit
tests to run when executed.
Travis integration is straightforward. Simply put
before_script:
- gem install inventory-rake -v '~> VERSION' --no-rdoc --no-ri
- rake gem:deps:install
in the project’s ‹.travis.yml› file, replacing ‹VERSION› with the version
of Inventory-Rake that you require. This’ll make sure that Travis installs
all development, runtime, and optional dependencies that you’ve listed in
your inventory before running any tests.
You might also need to put
env:
- RUBYOPT=rubygems
in your ‹.travis.yml› file, depending on how things are set up.
¹ Ruby project structure: http://guides.rubygems.org/make-your-own-gem/
² Semantic versioning: http://semver.org/
³ Inventory-Rake: http://disu.se/software/inventory-rake-1.0/
⁴ Travis: http://travis-ci.org/
⁵ Lookout-Rake: http://disu.se/software/lookout-rake-3.0/
§ API
If the guide above doesn’t provide you with all the answers you seek, you
may refer to the API¹ for more answers.
¹ See http://disu.se/software/inventory-1.0/api/Inventory/
§ Financing
Currently, most of my time is spent at my day job and in my rather busy
private life. Please motivate me to spend time on this piece of software
by donating some of your money to this project. Yeah, I realize that
requesting money to develop software is a bit, well, capitalistic of me.
But please realize that I live in a capitalistic society and I need money
to have other people give me the things that I need to continue living
under the rules of said society. So, if you feel that this piece of
software has helped you out enough to warrant a reward, please PayPal a
donation to now@disu.se¹. Thanks! Your support won’t go unnoticed!
¹ Send a donation:
https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now@disu.se&item_name=Inventory
§ Reporting Bugs
Please report any bugs that you encounter to the {issue tracker}¹.
¹ See https://github.com/now/inventory/issues
§ Authors
Nikolai Weibull wrote the code, the tests, the documentation, and this
README.
§ Licensing
Inventory is free software: you may redistribute it and/or modify it under
the terms of the {GNU Lesser General Public License, version 3}¹ or later²,
as published by the {Free Software Foundation}³.
¹ See http://disu.se/licenses/lgpl-3.0/
² See http://gnu.org/licenses/
³ See http://fsf.org/
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.0
Inventory-Rake
Inventory-Rake provides Rake¹ tasks for your Inventory². This includes tasks
for cleaning up our project, compiling extensions, installing dependencies,
installing and uninstalling the project itself, and creating and pushing
distribution files to distribution points.
¹ See http://rake.rubyforge.org/
² See http://disu.se/software/inventory-1.0/
§ Installation
Install Inventory-Rake with
% gem install inventory-rake
§ Usage
Include the following code in your ‹Rakefile›, where ‹Package› is the
top-level module of your project:
require 'inventory-rake-3.0'
load File.expand_path('../lib/package/version.rb', __FILE__)
Inventory::Rake::Tasks.define Package::Version
Inventory::Rake::Tasks.unless_installing_dependencies do
# Any additional tasks that your project’s dependencies provide
end
‹Inventory::Rake::Tasks.define› does the heavy lifting. It takes our
inventory and sets up the tasks mentioned above. We also do some
additional customization of the gem specification.
As we want to be able to use our Rakefile to install our dependencies for
us, the rest of the Rakefile is inside the conditional
#unless_installing_dependencies, which, as the name certainly implies,
executes its block unless the task being run is the one that installs our
dependencies. This becomes relevant if we want to, for example, set up
Travis¹ integration. To do so, simply add
before_script:
- gem install inventory-rake -v '~> VERSION' --no-rdoc --no-ri
- rake gem:deps:install
to your ‹.travis.yml› file. This’ll make sure that Travis installs all
development, runtime, and optional dependencies that you’ve listed in your
inventory before running any tests.
There’s more information in the {API documentation}² that you’ll likely
want to read up on if anything is unclear.
¹ See http://travis-ci.org/
² See http://disu.se/software/inventory-rake-1.0/api/Inventory/Rake/
§ Tasks
The tasks that are created if you use Inventory-Rake are:
= check. = Check that the package meets its expectations.
= mostlyclean. = Delete targets built by rake that are ofter rebuilt.
= clean. = Delete targets built by rake; depends on mostlyclean.
= distclean. = Delete all files not meant for distribution; depends on clean.
= compile. = Compile all extensions; depends on each compile:name.
= compile:name. = Compile extension /name/; depends on
lib/path/so file.
= lib/path/so. = Installed dynamic library of extension /name/ inside
inventory path; depends on ext/name/so.
= ext/name/so. = Dynamic library of extension /name/; depends on
ext/name/Makefile and the source files of the extension.
= ext/name/Makefile. = Makefile for extension /name/; depends on inventory
path, ext/name/extconf.rb file, and ext/name/depend file. Will be
created by extconf.rb, which may take options from environment variable
name#upcase_EXTCONF_OPTIONS or ‹EXTCONF_OPTIONS› if defined.
= clean:name. = Clean files built for extension /name/; depended upon by
clean.
= spec. = Create specifications; depends on gem:spec.
= gem:spec. = Create gem specification; depends on gemspec.
= gemspec (file). = Gem specification file; depends on Rakefile, README, and
inventory path.
= dist. = Create files for distribution; depends on gem:dist.
= gem:dist. = Create gem for distribution; depends on inventory:check and gem
file.
= inventory:check. = Check that the inventory is correct by looking for files
not listed in the inventory that match the pattern and for files listed
in the inventory that don’t exist; depends on distclean.
= gem (file). = Gem file; depends on files included in gem.
= dist:check. = Check files before distribution; depends on dist and
gem:dist:check.
= gem:dist:check. = Check gem before distribution; depends on gem:dist.
= deps:install. = Install dependencies on the local system; depends on
gem:deps:install.
= gem:deps:install. = Install dependencies in ruby gem directory.
= deps:install:user. = Install dependencies for the current user; depends on
gem:deps:install:user.
= gem:deps:install:user. = Install dependencies in the user gem directory.
= install. = Install distribution files on the local system; depends on
gem:install.
= gem:install. = Install gem in ruby gem directory; depends on gem:dist.
= install:user. = Install distribution files for the current user; depends on
gem:install:user.
= gem:install:user. = Install gem in the user gem directory.
= uninstall. = Delete all files installed on the local system.
= gem:uninstall. = Uninstall gem from ruby gem directory.
= uninstall:user. = Delete all files installed for current user.
= gem:uninstall:user. = Uninstall gem from ruby gem directory.
= push. = Push distribution files to distribution hubs.
= gem:push. = Push gem to rubygems.org.
§ Financing
Currently, most of my time is spent at my day job and in my rather busy
private life. Please motivate me to spend time on this piece of software
by donating some of your money to this project. Yeah, I realize that
requesting money to develop software is a bit, well, capitalistic of me.
But please realize that I live in a capitalistic society and I need money
to have other people give me the things that I need to continue living
under the rules of said society. So, if you feel that this piece of
software has helped you out enough to warrant a reward, please PayPal a
donation to now@disu.se¹. Thanks! Your support won’t go unnoticed!
¹ Send a donation:
https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now@disu.se&item_name=Inventory-Rake
§ Reporting Bugs
Please report any bugs that you encounter to the {issue tracker}¹.
¹ See https://github.com/now/inventory-rake/issues
§ Authors
Nikolai Weibull wrote the code, the tests, the manual pages, and this
README.
§ Licensing
Inventory-Rake is free software: you may redistribute it and/or modify it
under the terms of the {GNU Lesser General Public License, version 3}¹ or
later², as published by the {Free Software Foundation}³.
¹ See http://disu.se/licenses/lgpl-3.0/
² See http://gnu.org/licenses/
³ See http://fsf.org/
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.0
Lookout-Rake
Lookout-Rake provides Rake┬╣ tasks for testing using Lookout.
┬╣ See http://rake.rubyforge.org/
§ Installation
Install Lookout-Rake with
% gem install lookout-rake
§ Usage
Include the following code in your ‹Rakefile›:
require 'lookout-rake-3.0'
Lookout::Rake::Tasks::Test.new
If the ‹:default› task hasn’t been defined it’ll be set to depend on the
‹:test› task. The ‹:check› task will also depend on the ‹:test› task.
There’s also a ‹:test:coverage› task that gets defined that uses the
coverage library that comes with Ruby 1.9 to check the test coverage when
the tests are run.
You can hook up your test task to use your Inventory┬╣:
load File.expand_path('../lib/library-X.0/version.rb', __FILE__)
Lookout::Rake::Tasks::Test.new :inventory => Library::Version
Also, if you use the tasks that come with Inventory-Rake┬▓, the test task
will hook into the inventory you tell them to use automatically, that is,
the following will do:
load File.expand_path('../lib/library-X.0/version.rb', __FILE__)
Inventory::Rake::Tasks.define Library::Version
Lookout::Rake::Tasks::Test.new
For further usage information, see the {API documentation}┬│.
┬╣ Inventory: http://disu.se/software/inventory/
┬▓ Inventory-Rake: http://disu.se/software/inventory-rake/
┬│ API: http://disu.se/software/lookout-rake/api/Lookout/Rake/Tasks/Test/
§ Integration
To use Lookout together with Vim¹, place ‹contrib/rakelookout.vim› in
‹~/.vim/compiler› and add
compiler rakelookout
to ‹~/.vim/after/ftplugin/ruby.vim›. Executing ‹:make› from inside Vim
will now run your tests and an errors and failures can be visited with
‹:cnext›. Execute ‹:help quickfix› for additional information.
Another useful addition to your ‹~/.vim/after/ftplugin/ruby.vim› file may
be
nnoremap <buffer> <silent> <Leader>M <Esc>:call <SID>run_test()<CR>
let b:undo_ftplugin .= ' | nunmap <buffer> <Leader>M'
function! s:run_test()
let test = expand('%')
let line = 'LINE=' . line('.')
if test =~ '^lib/'
let test = substitute(test, '^lib/', 'test/', '')
let line = ""
endif
execute 'make' 'TEST=' . shellescape(test) line
endfunction
Now, pressing ‹<Leader>M› will either run all tests for a given class, if
the implementation file is active, or run the test at or just before the
cursor, if the test file is active. This is useful if youΓÇÖre currently
receiving a lot of errors and/or failures and want to focus on those
associated with a specific class or on a specific test.
┬╣ Find out more about Vim at http://www.vim.org/
§ Financing
Currently, most of my time is spent at my day job and in my rather busy
private life. Please motivate me to spend time on this piece of software
by donating some of your money to this project. Yeah, I realize that
requesting money to develop software is a bit, well, capitalistic of me.
But please realize that I live in a capitalistic society and I need money
to have other people give me the things that I need to continue living
under the rules of said society. So, if you feel that this piece of
software has helped you out enough to warrant a reward, please PayPal a
donation to now@disu.se┬╣. Thanks! Your support wonΓÇÖt go unnoticed!
┬╣ Send a donation:
https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now%40disu%2ese&item_name=Nikolai%20Weibull%20Software%20Services
§ Reporting Bugs
Please report any bugs that you encounter to the {issue tracker}┬╣.
┬╣ See https://github.com/now/lookout-rake/issues
§ Authors
Nikolai Weibull wrote the code, the tests, the manual pages, and this
README.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.24
[Deprecated] Core library for PayPal ruby SDKs
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.0
YARD-Heuristics
YARD-Heuristics heuristically determines types of parameters and return
values for YARD documentation that doesnΓÇÖt explicitly document it. This
allows you to write documentation that isnΓÇÖt adorned with ΓÇ£obviousΓÇ¥ types,
but still get that information into the output. It also lets you
nice-looking references to parameters and have them be marked up
appropriately in HTML output.
§ Heuristics
The following sections list the various heuristics that YARD-Heuristics
apply for determining types of parameters and return values.
Note that for all heuristics, a type will only be added if none already
exists.
§ Parameter Named “other”
A parameter named ΓÇ£otherΓÇ¥ has the same type as the receiver. This turns
class Point
def ==(other)
into
class Point
# @param [Point] other
def ==(other)
§ Parameter Types Derived by Parameter Name
Parameters to a method with names in the following table has the type
listed on the same row.
| Name | Type |
|--------+-----------|
| index | [Integer] |
| object | [Object] |
| range | [Range] |
| string | [String] |
Thus
class Point
def x_inside?(range)
becomes
class Point
# @param [Range] range
def x_inside?(range)
§ Block Parameters
If the last parameter to a methodΓÇÖs name begins with ΓÇÿ&ΓÇÖ it has the type
[Proc].
class Method
def initialize(&block)
becomes
class Method
# @param [Block] block
def initialize(&block)
§ Return Types by Method Name
For the return type of a method with less than two ‹@return› tags, the
method name is lookup up in the following table and has the type listed on
the same row. For the “type” “self or type”, if a ‹@param› tag exists with
the name ΓÇ£otherΓÇ¥, the type of the receiver is used, otherwise ΓÇ£selfΓÇ¥ is
used. For the ΓÇ£typeΓÇ¥ ΓÇ£typeΓÇ¥, the type of the receiver is used.
| Name | Type |
|-----------------+----------------|
| ‹<<› | self or type |
| ‹>>› | self or type |
| ‹==› | [Boolean] |
| ‹===› | [Boolean] |
| ‹=~› | [Boolean] |
| ‹<=>› | [Integer, nil] |
| ‹+› | type |
| ‹-› | type |
| ‹*› | type |
| ‹/› | type |
| each | [self] |
| each_with_index | [self] |
| hash | [Integer] |
| inspect | [String] |
| length | [Integer] |
| size | [Integer] |
| to_s | [String] |
| to_str | [String] |
Thus
class Point
def <<(other)
becomes
class Point
# @return [Point]
def <<(other)
but
class List
def <<(item)
becomes
class List
# @return [self]
def <<(item)
§ Emphasizing Parameter Names
When producing HTML output, any words in all uppercase, with a possible
“th” suffix, that is also the name of a parameter, an ‹@option›, or a
‹@yieldparam›, will be downcased and emphasized with a class of
ΓÇ£parameterΓÇ¥.
In the following example, ΓÇ£OTHERΓÇ¥ will be turned into
‹<em class="parameter">other</em>›:
class Point
# @return True if the receiverΓÇÖs class and {#x} and {#y} `#==` those of
# OTHER
def ==(other)
§ Usage
Add ‹--plugin yard-heuristics-1.0› to your YARD command line. If you’re
using Inventory-Rake-Tasks-YARD┬╣, add the following to your Rakefile:
Inventory::Rake::Tasks::YARD.new do |t|
t.options += %w'--plugin yard-heuristics-1.0'
end
┬╣ See http://disu.se/software/inventory-rake-tasks-yard/
§ API
ThereΓÇÖs really not very much to the YARD-Heuristics API. What you can do
is add (or modify) the types of parameters and return types of methods by
adding (or modifying) entries in the Hash tables
‹YARDHeuristics::ParamTypes› and ‹YARDHeuristics::ReturnTypes›
respectively. ThatΓÇÖs about it.
§ Financing
Currently, most of my time is spent at my day job and in my rather busy
private life. Please motivate me to spend time on this piece of software
by donating some of your money to this project. Yeah, I realize that
requesting money to develop software is a bit, well, capitalistic of me.
But please realize that I live in a capitalistic society and I need money
to have other people give me the things that I need to continue living
under the rules of said society. So, if you feel that this piece of
software has helped you out enough to warrant a reward, please PayPal a
donation to now@disu.se┬╣. Thanks! Your support wonΓÇÖt go unnoticed!
┬╣ Send a donation:
https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now@disu.se&item_name=YARD-Heuristics
§ Reporting Bugs
Please report any bugs that you encounter to the {issue tracker}┬╣.
┬╣ See https://github.com/now/yard-heuristics/issues
§ Authors
Nikolai Weibull wrote the code, the tests, and this README.
§ Licensing
YARD-Heuristics is free software: you may redistribute it and/or modify it
under the terms of the {GNU Lesser General Public License, version 3}┬╣ or
later┬▓, as published by the {Free Software Foundation}┬│.
┬╣ See http://disu.se/licenses/lgpl-3.0/
┬▓ See http://gnu.org/licenses/
┬│ See http://fsf.org/
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.0
Inventory-Rake-Tasks-YARD
Inventory-Rake-Tasks-YARD provides Rake┬╣ tasks for YARD┬▓ using your
Inventory┬│.
┬╣ See http://rake.rubyforge.org/
┬▓ See http://yardoc.org/
┬│ See http://disu.se/software/inventory/
§ Installation
Install Inventory-Rake-Tasks-YARD with
% gem install inventory-rake-tasks-yard
§ Usage
Include the following code in your ‹Rakefile› (assuming that you’ve already
set up Inventory-Rake┬╣:
Inventory::Rake::Tasks.unless_installing_dependencies do
require 'inventory-rake-tasks-yard-1.0'
Inventory::Rake::Tasks::YARD.new
end
ThisΓÇÖll define the following tasks:
= .yardopts (file). = Create .yardopts file; depends on the file defining
this task and Rakefile.
= html. = Generate documentation in HTML format for all lib files in the
inventory; depends on .yardopts file.
‹Inventory::Rake::Tasks::YARD› takes a couple of options, but the ones you
might want to adjust are
= :options. = The options to pass to YARD; will be passed to
`Shellwords.shelljoin`.
= :globals. = The globals to pass to YARD.
= :files. = The files to process; mainly used if you want to add additional
files to process beyond the lib files in the inventory.
The options passed to YARD will be augmented with any options you list in a
file named ‹.yardopts.task›, where ‹task› is the name of the Rake task
invoking YARD, for example, ‹.yardopts.html› for the default
HTML-generating task. You can use this to add options that are local to
your installation and should thus not be listed in the Rakefile itself.
See the {API documentation}┬▓ for more information.
┬╣ See http://disu.se/software/inventory-rake/
┬▓ See http://disu.se/software/inventory-rake-tasks-yard/api/Inventory/Rake/Tasks/YARD/
§ Financing
Currently, most of my time is spent at my day job and in my rather busy
private life. Please motivate me to spend time on this piece of software
by donating some of your money to this project. Yeah, I realize that
requesting money to develop software is a bit, well, capitalistic of me.
But please realize that I live in a capitalistic society and I need money
to have other people give me the things that I need to continue living
under the rules of said society. So, if you feel that this piece of
software has helped you out enough to warrant a reward, please PayPal a
donation to now@disu.se┬╣. Thanks! Your support wonΓÇÖt go unnoticed!
┬╣ Send a donation:
https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now%40disu%2ese&item_name=Inventory-Rake-Tasks-YARD
§ Reporting Bugs
Please report any bugs that you encounter to the {issue tracker}┬╣.
┬╣ See https://github.com/now/inventory-rake-tasks-yard/issues
§ Authors
Nikolai Weibull wrote the code, the tests, the manual pages, and this
README.
§ Licensing
Inventory-Rake-Tasks-YARD is free software: you may redistribute it and/or
modify it under the terms of the {GNU Lesser General Public License,
version 3}┬╣ or later┬▓, as published by the {Free Software Foundation}┬│.
┬╣ See http://disu.se/licenses/lgpl-3.0/
┬▓ See http://gnu.org/licenses/
┬│ See http://fsf.org/
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.25
[Deprecated] The PayPal REST SDK provides Ruby APIs to create, process and manage payment.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.04
Quickly build an online store with carts, orders, automatic email receipts and payment collection via Stripe, StripeConnect, PayPal and Moneris.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.15
[Deprecated.] The PayPal Merchant SDK provides Ruby APIs for processing payments, recurring payments, subscriptions and transactions using PayPal's Merchant APIs, which include Express Checkout, Recurring Payments, Direct Payment and Transactional APIs.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.15
Used for generated API clients
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.03
[Deprecated] The PayPal Permission SDK provides Ruby APIs for developers to request and obtain permissions from merchants and consumers, to execute APIs on behalf of them. The permissions include variety of operations from processing payments to accessing account transaction history
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.31
PayPal Express Checkout API Client for Instance, Recurring and Digital Goods Payment.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.0
Provides Paypal web payments standard support to nimbleshop
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.08
Accepting iDEAL, Bancontact, SOFORT Banking, Creditcard,
SEPA Bank transfer, SEPA Direct debit, PayPal,
KBC Payment Button, CBC Payment Button, Belfius Direct
Net, paysafecard, PODIUM Cadeaukaart and ING Home’Pay online
payments without fixed monthly costs or any punishing registration
procedures.'
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.0
YARD-Value
YARD-Value provides YARD¹ handlers for Value² objects. It’ll document
whether the Value is Comparable and what attributes are used in such
comparisons, its #initialize method, and its protected accessors.
¹ See http://yardoc.org/
² See http://disu.se/software/value-1.0/
You add the documentation to the Module#Value invocation. Any ‹@param› tags
are used both for the parameters to the #initialize method and for the
protected accessors.
This
class Point
# A point on a plane.
# @param [Integer] x
# @param [Integer] y
Value :x, :y
end
generates documentation similar to
class Point
# A point on a plane.
# @param [Integer] x
# @param [Integer] y
def initialize(x, y)
end
and this
class Point
# A point on a plane.
# @param [Integer] x The x coordinate of the receiver
# @param [Integer] y The y coordinate of the receiver
Value :x, :y
end
generates documentation similar to
class Point
# A point on a plane.
# @param [Integer] x
# @param [Integer] y
def initialize(x, y)
protected
# @return [Integer] The x coordinate of the receiver
attr_reader :x
# @return [Integer] The y coordinate of the receiver
attr_reader :y
end
For comparable Values, a note is added about what attributes are used in the
comparison. This
class Point
# A point on a plane.
# @param [Integer] x
# @param [Integer] y
Value :x, :y, :comparable => true
end
is similar to
class Point
# A point on a plane.
# @param [Integer] x
# @param [Integer] y
# @note Comparisons between instances are made between x and y.
def initialize(x, y)
end
§ Usage
Add ‹--plugin yard-value-1.0› to your YARD command line. If you’re
using Inventory-Rake-Tasks-YARD¹, add the following to your Rakefile:
Inventory::Rake::Tasks::YARD.new do |t|
t.options += %w'--plugin yard-value-1.0'
end
¹ See http://disu.se/software/inventory-rake-tasks-yard-1.0/
§ Financing
Currently, most of my time is spent at my day job and in my rather busy
private life. Please motivate me to spend time on this piece of software
by donating some of your money to this project. Yeah, I realize that
requesting money to develop software is a bit, well, capitalistic of me.
But please realize that I live in a capitalistic society and I need money
to have other people give me the things that I need to continue living
under the rules of said society. So, if you feel that this piece of
software has helped you out enough to warrant a reward, please PayPal a
donation to now@disu.se¹. Thanks! Your support won’t go unnoticed!
¹ Send a donation:
https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now@disu.se&item_name=YARD-Value
§ Reporting Bugs
Please report any bugs that you encounter to the {issue tracker}¹.
¹ See https://github.com/now/yard-value/issues
§ Authors
Nikolai Weibull wrote the code, the tests, and this README.
§ Licensing
YARD-Value is free software: you may redistribute it and/or modify it under
the terms of the {GNU Lesser General Public License, version 3}¹ or later²,
as published by the {Free Software Foundation}³.
¹ See http://disu.se/licenses/lgpl-3.0/
² See http://gnu.org/licenses/
³ See http://fsf.org/
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.03
PaypalExpress integration with Catarse crowdfunding platform
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.21
Lightweight wrapper for Paypal's Adaptive Payments API
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.03
A ruby library for handling paypal api's including IPNs
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity
0.23
PayPal Express Checkout API Client for recurring billing.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
Activity