Test Reporting

right_aws

== DESCRIPTION: The RightScale AWS gems have been designed to provide a robust, fast, and secure interface to Amazon EC2, EBS, S3, SQS, SDB, and CloudFront. These gems have been used in production by RightScale since late 2006 and are being maintained to track enhancements made by Amazon. The RightScale AWS gems comprise: - RightAws::Ec2 -- interface to Amazon EC2 (Elastic Compute Cloud) and the associated EBS (Elastic Block Store) - RightAws::S3 and RightAws::S3Interface -- interface to Amazon S3 (Simple Storage Service) - RightAws::Sqs and RightAws::SqsInterface -- interface to first-generation Amazon SQS (Simple Queue Service) (API version 2007-05-01) - RightAws::SqsGen2 and RightAws::SqsGen2Interface -- interface to second-generation Amazon SQS (Simple Queue Service) (API version 2008-01-01) - RightAws::SdbInterface and RightAws::ActiveSdb -- interface to Amazon SDB (SimpleDB) - RightAws::AcfInterface -- interface to Amazon CloudFront, a content distribution service == FEATURES: - Full programmmatic access to EC2, EBS, S3, SQS, SDB, and CloudFront. - Complete error handling: all operations check for errors and report complete error information by raising an AwsError. - Persistent HTTP connections with robust network-level retry layer using RightHttpConnection). This includes socket timeouts and retries. - Robust HTTP-level retry layer. Certain (user-adjustable) HTTP errors returned by Amazon's services are classified as temporary errors. These errors are automaticallly retried using exponentially increasing intervals. The number of retries is user-configurable. - Fast REXML-based parsing of responses (as fast as a pure Ruby solution allows). - Uses libxml (if available) for faster response parsing. - Support for large S3 list operations. Buckets and key subfolders containing many (> 1000) keys are listed in entirety. Operations based on list (like bucket clear) work on arbitrary numbers of keys. - Support for streaming GETs from S3, and streaming PUTs to S3 if the data source is a file. - Support for single-threaded usage, multithreaded usage, as well as usage with multiple AWS accounts. - Support for both first- and second-generation SQS (API versions 2007-05-01 and 2008-01-01). These versions of SQS are not compatible. - Support for signature versions 0 and 1 on SQS, SDB, and EC2. - Interoperability with any cloud running Eucalyptus (http://eucalyptus.cs.ucsb.edu) - Test suite (requires AWS account to do "live" testing).

3.1.0 • 12 years ago

excel_to_code

# Excel to Code [![Tests Passing](https://travis-ci.org/tamc/excel_to_code.svg?branch=master)](https://travis-ci.org/tamc/excel_to_code) excel_to_c - roughly translate some Excel files into C. excel_to_ruby - roughly translate some Excel files into Ruby. This allows spreadsheets to be: 1. Embedded in other programs, such as web servers, or optimisers 2. Without depending on any Microsoft code For example, running [these commands](examples/simple/compile.sh) turns [this spreadsheet](examples/simple/simple.xlsx) into [this Ruby code](examples/simple/ruby/simple.rb) or [this C code](examples/simple/c/simple.c). # Install Requires Ruby. Install by: gem install excel_to_code # Run To just have a go: excel_to_c <excel_file_name> This will produce a file called excelspreadsheet.c For a more complex spreadsheet: excel_to_c --compile --run-tests --settable <name of input worksheet> --prune-except <name of output worksheet> <excel file name> See the full list of options: excel_to_c --help # Gotchas, limitations and bugs 0. No custom functions, no macros for generating results 1. Results are cached. So you must call reset(), then set values, then read values. 2. It must be possible to replace INDIRECT and OFFSET formula with standard references at compile time (e.g., INDIRECT("A"&"1") is fine, INDIRECT(userInput&"3") is not. 3. Doesn't implement all functions. [See which functions are implemented](docs/Which_functions_are_implemented.md). 4. Doesn't implement references that involve range unions and lists (but does implement standard ranges) 5. Sometimes gives cells as being empty, when excel would give the cell as having a numeric value of zero 6. The generated C version does not multithread and will give bad results if you try. 7. The generated code uses floating point, rather than fully precise arithmetic, so results can differ slightly. 8. The generated code uses the sprintf approach to rounding (even-odd) rather than excel's 0.5 rounds away from zero. 9. Ranges like this: Sheet1!A10:Sheet1!B20 and 3D ranges don't work. Report bugs: <https://github.com/tamc/excel_to_code/issues> # Changelog See [Changes](CHANGES.md). # License See [License](LICENSE.md) # Hacking Source code: <https://github.com/tamc/excel_to_code> Documentation: * [Installing from source](docs/installing_from_source.md) * [Structure of this project](docs/structure_of_this_project.md) * [How does the calculation work](docs/how_does_the_calculation_work.md) * [How to fix parsing errors](docs/How_to_fix_parsing_errors.md) * [How to implement a new Excel function](docs/How_to_add_a_missing_function.md) Some notes on how Excel works under the hood: * [The Excel file structure](docs/implementation/excel_file_structure.md) * [Relationships](docs/implementation/relationships.md) * [Workbooks](docs/implementation/workbook.md) * [Worksheets](docs/implementation/worksheets.md) * [Cells](docs/implementation/cell.md) * [Tables](docs/implementation/tables.md) * [Shared Strings](docs/implementation/shared_strings.md) * [Array formulae](docs/implementation/array_formulae.md)

0.3.20 • 3 years ago

inventory

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/

1.5.3 • 9 years ago

lookout

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/

3.0.1 • 11 years ago

value

Value Value is a library for defining immutable value objects in Ruby. A value object is an object whose equality to other objects is determined by its value, not its identity, think dates and amounts of money. A value object should also be immutable, as you donΓÇÖt want the date ΓÇ£2013-04-22ΓÇ¥ itself to change but the current date to change from ΓÇ£2013-04-22ΓÇ¥ to ΓÇ£2013-04-23ΓÇ¥. That is, you donΓÇÖt want entries in a calendar for 2013-04-22 to move to 2013-04-23 simply because the current date changes from 2013-04-22 to 2013-04-23. A value object consists of one or more attributes stored in instance variables. Value sets up an #initialize method for you that letΓÇÖs you set these attributes, as, value objects being immutable, thisΓÇÖll be your only chance to do so. Value also adds equality checks ΓÇ╣#==ΓÇ║ and ΓÇ╣#eql?ΓÇ║ (which are themselves equivalent), a ΓÇ╣#hashΓÇ║ method, a nice ΓÇ╣#inspectΓÇ║ method, and a protected attribute reader for each attribute. You may of course add any additional methods that your value object will benefit from. ThatΓÇÖs basically all thereΓÇÖs too it. LetΓÇÖs now look at using the Value library. ┬º Usage You create value object class by invoking ΓÇ╣#ValueΓÇ║ inside the class (module) you wish to make into a value object class. LetΓÇÖs create a class that represent points on a plane: class Point Value :x, :y end A ΓÇ╣PointΓÇ║ is thus a value object consisting of two sub-values ΓÇ╣xΓÇ║ and ΓÇ╣yΓÇ║ (the coordinates). Just from invoking ΓÇ╣#ValueΓÇ║, a ΓÇ╣PointΓÇ║ object will have a constructor that takes two arguments to set instance variables ΓÇ╣@xΓÇ║ and ΓÇ╣@yΓÇ║, equality checks ΓÇ╣#==ΓÇ║ and ΓÇ╣#eql?ΓÇ║ (which are the same), a ΓÇ╣#hashΓÇ║ method, a nice ΓÇ╣#inspectΓÇ║ method, and two protected attribute readers ΓÇ╣#xΓÇ║ and ΓÇ╣#yΓÇ║. We can thus already creat ΓÇ╣PointΓÇ║s: origo = Point.new(0, 0) The default of making the attribute readers protected is often good practice, but for a ΓÇ╣PointΓÇ║ it probably makes sense to be able to access its coordinates: class Point public(*attributes) end ThisΓÇÖll make all attributes of ΓÇ╣PointΓÇ║ public. You can of course choose to only make certain attributes public: class Point public :x end Note that this public is standard Ruby functionality. Adding a method to ΓÇ╣PointΓÇ║ is of course also possible and very much Rubyish: class Point def distance(other) Math.sqrt((other.x - x)**2 + (other.y - y)**2) end end For some value object classes you might want to support optional attributes. This is done by providing a default value for the attribute, like so: class Money Value :amount, [:currency, :USD] end Here, the ΓÇ╣currencyΓÇ║ attribute will default to ΓÇ╣:USDΓÇ║. You can create ΓÇ╣MoneyΓÇ║ via dollars = Money.new(2) but also kronor = Money.new(2, :SEK) All required attributes must come before any optional attributes. Splat attributes are also supported: class List Value :'*elements' end empty = List.new suits = List.new(:spades, :hearts, :diamonds, :clubs) Splat attributes are optional. Finally, block attributes are also available: class Block Value :'&block' end block = Block.new{ |e| e * 2 } Block attributes are optional. Comparison beyond ΓÇ╣#==ΓÇ║ is possible by specifingy the ΓÇ╣:comparableΓÇ║ option to ΓÇ╣#ValueΓÇ║, listing one or more attributes that should be included in the comparison: class Vector Value :a, :b, :comparable => :a end Note that equality (ΓÇ╣#==ΓÇ║ and ΓÇ╣#eql?ΓÇ║) is always defined based on all attributes, regardless of arguments to ΓÇ╣:comparableΓÇ║. Here we say that comparisons between ΓÇ╣VectorΓÇ║s should be made between the values of the ΓÇ╣aΓÇ║ attribute only. We can also make comparisons between all attributes of a value object: class Vector Value :a, :b, :comparable => true end To sum things up, letΓÇÖs use all possible arguments to ΓÇ╣#ValueΓÇ║ at once: class Method Value :file, :line, [:name, 'unnamed'], :'*args', :'&block', :comparable => [:file, :line] end A ΓÇ╣MethodΓÇ║ consists of file and line information, a possible name, some arguments, possibly a block, and is comparable on the file and line on which they appear. Check out the {full API documentation}┬╣ for a more explicit description, should you need it or should you want to extend it. ┬╣ See http://disu.se/software/value/api/ ┬º 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=Value ┬º Reporting Bugs Please report any bugs that you encounter to the {issue tracker}┬╣. ┬╣ See https://github.com/now/value/issues ┬º Authors Nikolai Weibull wrote the code, the tests, the manual pages, and this README. ┬º Licensing 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/

1.1.3 • 11 years ago

right_aws

diff-lcs

ci_reporter

slather

codeclimate-test-reporter

knapsack

report_builder

statsample

allure-rspec

allure-cucumber

danger-junit

excel_to_code

relevance-rcov

coco

ci_reporter_test_unit

buildkite-test_collector

danger-simplecov_json

inventory

assert_difference

cql

lookout

minitest-gcstats

cuporter

rspec-tracer

perfecto-reporting

swiftrail

codeclimate_circle_ci_coverage

spicycode-rcov

fastlane-plugin-forsis

gunter_reporter

rspec-sonarqube-formatter

crazy_ivan

test-unit-runner-junitxml

rutema

robottelo_reporter

decc_2050_model

parallel_report_portal

rspec-tap-formatters

routes_coverage

jasmine-coverage

one9

value

route_dog

bad_link_finder

charlie

rutemaweb

josh-splat

qat-cucumber

finnlabs-ci_reporter

rutema_web