Organization

Version 13 (Brian Ford, 02/10/2009 11:29 AM)

1 1
h1. Organization
2 1
3 5 Brian Ford
There are many conceivable ways to organize the spec files. The structure is based on the Ruby language as well as the major components of a Ruby implementation.
4 1
5 8 Brian Ford
The goal is to maintain locality by grouping related specs. Generally, there is a single element (method, syntax element) per file, and the files are organized into three main directories: language, core, and library. Below is a partial graphic of the directory tree.
6 2 Brian Ford
7 1
8 7 Arthur Schreiber
   spec
9 7 Arthur Schreiber
   |-- core
10 7 Arthur Schreiber
   |     + -- array
11 7 Arthur Schreiber
   |     + -- bignum
12 7 Arthur Schreiber
   |     + -- binding
13 7 Arthur Schreiber
   |     + -- class
14 7 Arthur Schreiber
   |     + -- ...
15 7 Arthur Schreiber
   |     + -- time
16 7 Arthur Schreiber
   |     + -- true
17 7 Arthur Schreiber
   |     + -- unboundmethod
18 7 Arthur Schreiber
   |-- fixtures
19 7 Arthur Schreiber
   |-- language
20 7 Arthur Schreiber
   +-- library
21 7 Arthur Schreiber
         + -- enumerator
22 7 Arthur Schreiber
         + -- ...
23 7 Arthur Schreiber
         + -- time
24 7 Arthur Schreiber
         + -- yaml
25 1
26 8 Brian Ford
27 8 Brian Ford
h2. Syntax-sensitive Specs
28 8 Brian Ford
29 8 Brian Ford
There are three primary challenges in combining the 1.8 and 1.9 specs:
30 8 Brian Ford
31 8 Brian Ford
# Syntax differences
32 8 Brian Ford
# Methods that behave differently
33 8 Brian Ford
# Libraries or classes that are not part of the version
34 8 Brian Ford
35 8 Brian Ford
The three issues above are addressed as follows:
36 8 Brian Ford
37 12 Brian Ford
# Put any syntax-sensitive specs into a version-specific file and use the @language_version@ helper to conditionally run those specs. See "MSpec Helpers":/wiki/mspec/Helpers and the @language/method_spec.rb@ specs for examples.
38 13 Brian Ford
# Use ruby_version_is guards as usual for any methods or method behaviors specific to a particular version. See "MSpec Guards":/wiki/rubyspec/Guards.
39 12 Brian Ford
# Add exclusion lines to the :files config setting in either ruby.1.8.mspec or ruby.1.9.mspec for libraries or classes that should not be run in the respective version. See "MSpec Configuration":/wiki/mspec/Configuration.
40 2 Brian Ford
41 2 Brian Ford
h2. Language
42 2 Brian Ford
43 3 Brian Ford
The @language@ directory contains specs for the Ruby language proper. There are numerous possible ways of categorizing the entities and concepts that make up a programming language. Ruby has a fairly large number of reserved words. These words significantly describe major elements of the language, including flow control constructs like "for" and "while", conditional execution like "if" and "unless", exceptional execution control like "rescue", etc. There are also literals for the basic "types" like String, Regexp, Array and Fixnum.
44 2 Brian Ford
45 2 Brian Ford
Behavioral specifications describe the behavior of concrete entities. Rather than using concepts of computation to organize these spec files, we use entities of the Ruby language. Consider looking at any syntactic element of a Ruby program. With (almost) no ambiguity, one can identify it as a literal, reserved word, variable, etc.
46 2 Brian Ford
47 3 Brian Ford
There is a spec file that corresponds to each literal construct and most reserved words, with the exceptions noted below. There are also several files that are more difficult to classify: all predefined variables, constants, and objects (@predefined_spec.rb@), the precedence of all operators (@precedence_spec.rb@), the behavior of assignment to variables (@variables_spec.rb@), the behavior of subprocess execution (@execution_spec.rb@), the behavior of the raise method as it impacts the execution of a Ruby program (@raise_spec.rb@), and the block entities like "begin", "do", "{ ... }" (@block_spec.rb@).
48 2 Brian Ford
49 2 Brian Ford
Several reserved words and other entities are combined with the primary reserved word or entity to which they are related:
50 2 Brian Ford
51 2 Brian Ford
# predefined_spec.rb: false, true, nil, self
52 2 Brian Ford
# for_spec.rb: in
53 2 Brian Ford
# if_spec.rb: then, elsif
54 2 Brian Ford
# case_spec.rb: when
55 2 Brian Ford
# throw_spec.rb: catch
56 2 Brian Ford
57 2 Brian Ford
h2. Core library
58 2 Brian Ford
59 2 Brian Ford
The @core@ directory contains specs for the Ruby core library. These include classes such as Array, String, Regexp, Range, Fixnum, Float, etc. The @core@ directory contains a subdirectory named after the classes in the core library. For example, specs for the Array class are in the @array@ directory.
60 2 Brian Ford
61 4 Brian Ford
Within each subdirectory of @core@, the specs for each method of that class are placed in a separate file. For example, specs for Array#compact are places in @spec/core/array/compact_spec.rb@. Method names with characters like "?", "=", and "!" are in files named by stripping those characters. For example, specs for Array#compact! are in the same file as specs for Array#compact. All the spec files that are needed have already likely been created. (See the documentation for "mkspec":/wiki/mspec/Mkspec for details.)
62 2 Brian Ford
63 2 Brian Ford
h2. Standard library
64 2 Brian Ford
65 2 Brian Ford
The @library@ directory contains specs for the classes of the Ruby standard library. The same naming convention used in the @core@ directory applies here as well.