{"id":13777983,"url":"https://github.com/nwops/puppet-retrospec","last_synced_at":"2025-04-04T22:05:52.864Z","repository":{"id":637342,"uuid":"13027319","full_name":"nwops/puppet-retrospec","owner":"nwops","description":"The only tool you need to generate puppet code, tests, modules, facts, types, providers, data and everything else.","archived":false,"fork":false,"pushed_at":"2024-03-25T19:38:41.000Z","size":6986,"stargazers_count":137,"open_issues_count":35,"forks_count":26,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-03-28T21:04:10.144Z","etag":null,"topics":["devops","generator","magic","puppet","ruby"],"latest_commit_sha":null,"homepage":" https://www.retrospec-puppet.com/ ","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"agpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/nwops.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2013-09-23T04:59:29.000Z","updated_at":"2024-08-01T14:27:36.000Z","dependencies_parsed_at":"2024-06-21T14:16:08.968Z","dependency_job_id":"25098c31-6ee5-45d1-91ed-ee1663b3889f","html_url":"https://github.com/nwops/puppet-retrospec","commit_stats":{"total_commits":247,"total_committers":8,"mean_commits":30.875,"dds":"0.43724696356275305","last_synced_commit":"e20ded9b7b3d89c7ae9e39283dd9b1bb4f50f059"},"previous_names":[],"tags_count":33,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Fpuppet-retrospec","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Fpuppet-retrospec/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Fpuppet-retrospec/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Fpuppet-retrospec/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/nwops","download_url":"https://codeload.github.com/nwops/puppet-retrospec/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247256110,"owners_count":20909240,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["devops","generator","magic","puppet","ruby"],"created_at":"2024-08-03T18:00:50.263Z","updated_at":"2025-04-04T22:05:52.836Z","avatar_url":"https://github.com/nwops.png","language":"Ruby","readme":"Puppet-Retrospec\n================\nA retrospec plugin for puppet that generates puppet rspec test code based on the current code inside your module.\n\nProper testing is hard especially when you are new to ruby, rspec or even puppet.\n\nRetrospec makes it dead simple to get started with advanced puppet module development.  Retrospec will scan you puppet module files and actually write some very basic rspec-puppet test code.  Thus this gem will retrofit your existing puppet module with everything needed to get going with puppet unit testing.  Additionally, retrospec will outfit your module with any file you can think of.  Say goodbye to repetitive module setup.\n\nNot only will retrospec generate tests for you, it will also assist in creating many of the advanced puppet module files like custom facts, functions, types, providers and schemas, as well as their associated test files. It will even create the module from scratch if so desired.\n\nThe project was named retrospec because there are many times when you need to retrofit your module with various things.\n\nIf you like this project, star it and tell people!\n\nSee the [Website](https://www.puppet-retrospec.com)\n\nTable of Contents\n=================\n\n  * [Build Status](#build-status)\n  * [News](#news)\n  * [Install](#install)\n  * [How to use](#usage)\n    * [Module Path](#module-path)\n    * [Command Line Help](#command-line-help)\n  * [Design Goals](#design-goals)\n  * [Using the Generators](#using-the-generators)\n    * [Auto spec file creation](#auto-spec-file-creation)\n    * [Creating a new puppet module](#creating-a-new-puppet-module)\n    * [Creating a new fact](#creating-a-new-fact)\n    * [Creating a new provider](#creating-a-new-provider)\n    * [Creating a new function](#creating-a-new-function)\n    * [Creating a new type](#creating-a-new-type)\n    * [Creating a schema file](#creating-a-new-module-schema-file)\n  * [Enable Future Parser](#enabling-the-future-parser)\n  * [Configuration](#configuration)\n  * [Example](#example)\n  * [About the test suite](#about-the-test-suite)\n  * [How Does it do this](#how-does-it-do-this)\n  * [Beaker Testing](#beaker-testing)\n  * [Troubleshooting](#troubleshooting)\n  * [Running Tests](#running-tests)\n  * [Understanding Variable Resolution](#understanding-variable-resolution)\n  * [Todo](#todo)\n  * [Future Parser Support](#future-parser-support)\n  * [Paid Support](#paid-support)\n\nTOC Created by [gh-md-toc](https://github.com/ekalinin/github-markdown-toc)\n\n## Build Status\n![Build Status](https://gitlab.com/nwops/puppet-retrospec/badges/master/build.svg)\n[![Gem Version](https://badge.fury.io/rb/puppet-retrospec.svg)](http://badge.fury.io/rb/puppet-retrospec)\n\n## News\n### 10/11/17\nAdds the ability to generate puppet bolt tasks, parameters with some predefined language types\n\n`retrospec puppet new_task -n reboot -t bash -p \"name, count, amount\"`\n\nGenerates the parameters file and task file.\n\n\n### 5/10/17\nAdds ability to create module data.  With the release of puppet 4.9 we can now use module data.  \nUse the module_data generater to auto setup module data in your puppet module.  `retrospec puppet module_data`\n\n### 4/20/17\nWith all the changes in hiera recently and the ability to provide data in puppet modules.  I thought it would be a good\ntime to create a generator for retrospec to create hiera backends and data in module scaffolding. With the 1.6.0 release\nyou are now a simple step away to retrofitting data into your module.\n\nJust run `retrospec puppet module_data` to auto create the scaffolding.\n\nNote: You must be using puppet 4.7+ (PE 2016.4.x) to actually use data in a module, but there is nothing stopping\nyou from creating the scaffolding.\n\nNote: If you are using puppet 4.7-4.8 you will need to add `data_provider: \"hiera\"` in your module's metadata.json file.\n\n### 3/7/17\nYou can now sync files.  Any template file that contains a `.sync` in the file name will automatically\nbe syncronized.  This is especially helpful for Gemfiles, Rakefiles and other static files that need to be updated.\n### 2/1/17\nYou can now choose to overwrite files!  This is very useful when updating old module code with newer content.\nSee Usage below for how to enable.\n\n## Install\n`gem install puppet-retrospec`  \n\nThis will also install the retrospec framework that is required to use the plugin.\n\n## Usage\nThe easiest way to get started using retrospec-puppet is to run `retrospec puppet`\nfrom within your module directory. Retrospec uses the current directory if no options\nare specified.  Expect to run `retrospec puppet` multiple times throughout the day.\nRetrospec will never overwrite a file, so if something already exists retrospec will\nskip the file. Many times you will find yourself deleting existing files and allowing retrospec to recreate them based on updated templates.\n\n### Overwriting files\nAs stated above retrospec will not overwrite your files.  However, sometimes recreating files is desired as you change\nyour code.  Before '1.3' it was not possible to overwrite files, but now we can safely specify which files should be\noverwritten.  This feature is off by default so you will need to enable it.\n\nTo enable please use the global options `--enable-overwrite` or if you want everything `--enable-overwrite-all`\n\nNote: Enabling this feature will prompt you before running destructive operations like:  `y/n/a` where `a` means all.\n\n```\nretrospec -h\nA framework to automate your development workflow by generating common files and test patterns.\n\nUsage: retrospec [global options] plugin [plugin options]\nAvailable subcommands:\npuppet\n  -e, --enable-overwrite        Enable overwriting of files, will prompt for each file\n  -n, --enable-overwrite-all    Always overwrites files without prompting\n  -m, --module-path=\u003cs\u003e         The path (relative or absolute) to the module directory (default: /Users/cosman/github/puppet-retrospec)\n  -c, --config-map=\u003cs\u003e          The global retrospec config file (default: /Users/cosman/.retrospec/config.yaml)\n  -a, --available-plugins       Show an online list of available plugins\n  -v, --version                 Print version and exit\n  -h, --help                    Show this message\n\n```\n### Module Path\nBy default the module path is dynamically set based on the current directory.\nIf you need to point to a directory outside the current directory you can use the `--module_path` option.  This option is built into the retrospec framework\nso be sure to use `retrospec -m path_to_module`.\n\n### Command Line Help\nThere is a `-h` at every level of commands and subcommands.\n\n - `retrospec -h`\n - `retrospec puppet -h`\n - `retrospec puppet \u003csub_command\u003e -h`\n\n```\n[puppet@puppetdev ~]$ retrospec -m /tmp/test3323 puppet -h\nGenerates puppet rspec test code based on the classes and defines inside the manifests directory.\n\nSubcommands:\nnew_module\nnew_fact\nnew_type\nnew_provider\nnew_function\n\n  -t, --template-dir=\u003cs\u003e        Path to templates directory (only for overriding Retrospec templates)\n                                (default: /Users/cosman/.retrospec/repos/retrospec-puppet-templates)\n  -s, --scm-url=\u003cs\u003e             SCM url for retrospec templates (default:\n                                https://github.com/nwops/retrospec-templates)\n  -n, --name=\u003cs\u003e                The name of the module you wish to create (default: test3323)\n  -b, --branch=\u003cs\u003e              Branch you want to use for the retrospec template repo (default: master)\n  -a, --namespace=\u003cs\u003e           The namespace to use only when creating a new module (default: namespace)\n  -e, --enable-beaker-tests     Enable the creation of beaker tests\n  -v, --version                 Print version and exit\n  -h, --help                    Show this message  -h, --help                    Show this message\n```\n\n## Design Goals\nOne of the design goals of this plugin is to try to introspect as much information as possible so we don't need input from the user. If you are not sure what default values are used, use the `-h` option and the defaults will be revealed. Most of the defaults are dynamic.  \n\nAnother design goal is to allow the user to configure every option so that passing\nadditional options is not required when configured correctly.  Please see the [Configuration Section](#configuration) for setting a config file.\n\n## Using the Generators\nAt this time the generators are limited to just creating facts, providers, types, functions and schemas. As time goes on I envision more complicated puppet customizations like faces, indirectors, reports, or whatever else the community deems important.\n\n*Note:* the unit tests files created are only meant to get you started. Be aware that these unit test templates are not perfect and will need further refinement. Testing in this area is not well documented so its based of my own experience and imperfect.  Please submit a PR if you find ways to improve these [templates](https://github.com/nwops/retrospec-templates).  \n\n### Auto spec file creation\nEach generator will also create associated test files by default without having to use the generator command.  So if there is a existing module without tests for one of these things, retrospec will create the test files automatically. There is no need to run the generator subcommands to generate spec files for existing puppet module ruby files.  \n\n### Creating a new puppet module\nYou can create a puppet module from scratch using retrospec.\nThis can be compared to using `puppet module generate` with a skeleton. Retrospec\ndiffers slightly in that you can specify which skeleton/templates to use at creation time.  This is helpful when working with different clients or puppet versions.\nUnlike `puppet module generate` retrospec does not force you to create a\ndirectory with a namespace.  This means you do not need to rename anything after creating it. By default retrospec will consult the retrospec config file for default settings which can be overridden on the command line.  Having the config in place can save you a few key strokes.\n\n```\n# use -m to specify the module path\nretrospec -m /tmp/test_module_123 puppet new_module -n lmc-test123\n# or without specifying module_path\ncd /tmp/modules\nexport RETROSPEC_PUPPET_AUTO_GENERATE=true\nretrospec puppet new_module -n lmc-test124\n + /private/tmp/modules/lmc-test124/manifests/\n + /private/tmp/modules/lmc-test124/manifests/init.pp  \n + /private/tmp/modules/lmc-test124/metadata.json\n```\n\n### Creating a new fact\nCreating a new fact is easy with retrospec. Just use the following to\ncreate a fact and unit test.\n```\nretrospec -m /tmp/test_module_123 puppet new_fact -n datacenter\nSuccessfully ran hook: /Users/cosman/github/retrospec-templates/clone-hook\n + /private/tmp/modules/test123/lib/facter/\n + /private/tmp/modules/test123/lib/facter/datacenter.rb\n + /private/tmp/modules/test123/spec/unit/facter/\n + /private/tmp/modules/test123/spec/unit/facter/datacenter_spec.rb\n```\n\n### Creating a new provider\nCreate a new provider is easy.  Just specify the puppet type you want the generator\nto use and the stub code for a provider and provider test file will be created.\n\n```\ncd testabc124\nretrospec puppet new_provider -t package -n ibm_pkg\nSuccessfully ran hook: /Users/user1/retrospec-templates/clone-hook\n\n + /tmp/testabc124/lib/puppet/provider/package/\n + /tmp/testabc124/lib/puppet/provider/package/ibm_pkg.rb\nSuccessfully ran hook: /Users/user1/retrospec-templates/pre-hook\n```\n### Creating a new function\nCreating a new function is just as easy as other generators. Use the new_function\nsub command and specify the name.  Specify `--type v4` if you wish to create\na new 'v4' function, otherwise v3 is the default. Since testing functions\ncan be done in both rspec-ruby and rspec-puppet you can specify the test type as\nwell and retrospec will default to `rspec-puppet`.\n\n```\ncd testabc124\nretrospec puppet new_function -n is_url\nSuccessfully ran hook: /Users/user1/retrospec-templates/clone-hook\n+ /private/tmp/testabc124/lib/puppet/parser/functions/\n+ /private/tmp/testabc124/lib/puppet/parser/functions/is_url.rb\n```\n\n### Creating a new type\nCreating a type is similar to any other generator. You can specify which parameters,\nproperties, and providers to generate. Retrospec will generate a default provider\nif none are specified.\n\n```\nretrospec puppet new_type -n test_type --parameters param1 param2 --properties prop1 prop2 --providers default\nSuccessfully ran hook: /Users/user1/retrospec-templates/clone-hook\n\n + /private/tmp/testabc124/lib/puppet/type/\n + /private/tmp/testabc124/lib/puppet/type/test_type.rb\n + /private/tmp/testabc124/lib/puppet/provider/test_type/\n + /private/tmp/testabc124/lib/puppet/provider/test_type/default.rb\nSuccessfully ran hook: /Users/user1/retrospec-templates/pre-hook\n```\n### Creating a new module schema file\nSchema files are something I came up with recently and something I have found useful for various things. These schema files map all the puppet parameters in the classes and defines you have inside your module. You can use these schema files for validating hiera, generating documentation, or to serve as parameter documentation.  At this time the generator map only known datatypes so its up to you to define some of the complex data structures you have for puppet parameters.\nMaintaining a schema file is optional, but is incredible useful for people using your module and validating hiera data. Schema files are generated by default with every `retrospec puppet` run.\n\n```\ncd testabc124\nretrospec puppet\n+ /private/tmp/testabc124/testabc124_schema.yaml\n```\n\n## Configuration\n Below is a list of options that you can set in the config file.  Setting these options will help cut down on passing parameters. (/Users/username/.retrospec/config.yaml)  `retrospec -h`\n\n *Note:* if might be useful to have several config files for different clients or\n situations where you want to easily swap out templates or options.\n `retrospec --config-map /Users/user1/.retrospec/client1.yaml`\n\n```yaml\n# used by the main puppet plugin and every subcommand\nplugins::puppet::templates::url: https://github.com/nwops/retrospec-templates\nplugins::puppet::templates::ref: master\nplugins::puppet::enable_beaker_tests: true\nplugins::puppet::enable_future_parser: true\nplugins::puppet::template_dir: /Users/username/.retrospec/repos/retrospec-puppet-templates\n# used when creating new modules\nplugins::puppet::namespace: organization\nplugins::puppet::default_license: 'Apache-2.0'\nplugins::puppet::author: your_name\n# used when creating new functions\nplugins::puppet::default_function_version: v3\nplugins::puppet::default_function_test_type: rspec\n\n\n```\n\n*Note:* your not required to set any of these as they can be specified on the cli and also default to reasonable values.\n\n## Example\nBelow you can see that it creates files for every resource in the apache module in addition to other files that you need for unit testing puppet code. Rspec-puppet best practices says to put definitions in a defines folder and classes in a classes folder since it infers what kind of resource it is based on this convention.  Retrospec sets up this scaffolding for you.  Don't like the files that came with your module?  Simply delete the files and regenerate them with `puppet retrospec`.\n\n```shell\n$ pwd\n/Users/cosman/github/puppetlabs-apache\n$ retrospec puppet\n + /Users/cosman/github/puppetlabs-apache/Gemfile\n  + /Users/cosman/github/puppetlabs-apache/Rakefile\n  + /Users/cosman/github/puppetlabs-apache/spec/\n  + /Users/cosman/github/puppetlabs-apache/spec/shared_contexts.rb\n  + /Users/cosman/github/puppetlabs-apache/spec/spec_helper.rb\n  + /Users/cosman/github/puppetlabs-apache/.fixtures.yml\n  + /Users/cosman/github/puppetlabs-apache/.gitignore\n  + /Users/cosman/github/puppetlabs-apache/.travis.yml\n  + /Users/cosman/github/puppetlabs-apache/spec/classes/\n  + /Users/cosman/github/puppetlabs-apache/spec/classes/default_mods_spec.rb\n  + /Users/cosman/github/puppetlabs-apache/spec/classes/dev_spec.rb\n  + /Users/cosman/github/puppetlabs-apache/spec/classes/mod/disk_cache_spec.rb\n  + /Users/cosman/github/puppetlabs-apache/spec/classes/service_spec.rb\n  + /Users/cosman/github/puppetlabs-apache/spec/classes/ssl_spec.rb\n  + /Users/cosman/github/puppetlabs-apache/spec/defines/\n  + /Users/cosman/github/puppetlabs-apache/spec/defines/balancer_spec.rb\n  + /Users/cosman/github/puppetlabs-apache/spec/defines/balancermember_spec.rb\n  + /Users/cosman/github/puppetlabs-apache/spec/defines/vhost_spec.rb\n\n```\n\nLooking at the file we can see that it did a lot of work for us.  Retrospec generated many tests automatically. However the variable resolution isn't perfect so you will need to manually resolve some variables.  This doesn't produce 100% coverage but all you did was press enter to produce all this anyways. Below is the classes/apache_spec.rb file.  Notice that while Retrospec created all these files, you still need to do more work.\nRetrospec is only here to setup your module for testing, which might save you several hours each time you create a module. Below I'll go through the different parts of automation that you can use in your testing.\n\n\n```ruby\nrequire 'spec_helper'\nrequire 'shared_contexts'\n\ndescribe 'apache' do\n  # by default the hiera integration uses hiera data from the shared_contexts.rb file\n  # but basically to mock hiera you first need to add a key/value pair\n  # to the specific context in the spec/shared_contexts.rb file\n  # Note: you can only use a single hiera context per describe/context block\n  # rspec-puppet does not allow you to swap out hiera data on a per test block\n  #include_context :hiera\n\n\n  # below is the facts hash that gives you the ability to mock\n  # facts on a per describe/context block.  If you use a fact in your\n  # manifest you should mock the facts below.\n  let(:facts) do\n    {}\n  end\n  # below is a list of the resource parameters that you can override.\n  # By default all non-required parameters are commented out,\n  # while all required parameters will require you to add a value\n  let(:params) do\n    {\n      #:default_mods =\u003e true,\n      #:default_vhost =\u003e true,\n      #:default_ssl_vhost =\u003e false,\n      #:default_ssl_cert =\u003e $apache::params::default_ssl_cert,\n      #:default_ssl_key =\u003e $apache::params::default_ssl_key,\n      #:default_ssl_chain =\u003e undef,\n      #:default_ssl_ca =\u003e undef,\n      #:default_ssl_crl_path =\u003e undef,\n      #:default_ssl_crl =\u003e undef,\n      #:service_enable =\u003e true,\n      #:logroot =\u003e $apache::params::logroot,\n      #:ports_file =\u003e $apache::params::ports_file,\n      #:server_tokens =\u003e \"OS\",\n      #:server_signature =\u003e \"On\",\n    }\n  end\n  # add these two lines in a single test block to enable puppet and hiera debug mode\n  # Puppet::Util::Log.level = :debug\n  # Puppet::Util::Log.newdestination(:console)\n  it do\n    is_expected.to contain_package('httpd').\n             with({\"ensure\"=\u003e\"installed\",\n                   \"name\"=\u003e\"$apache::params::apache_name\",\n                   \"notify\"=\u003e\"Class[Apache::Service]\"})\n  end\n  it do\n    is_expected.to contain_group('$apache::params::group').\n             with({\"ensure\"=\u003e\"present\",\n                   \"require\"=\u003e\"Package[httpd]\"})\n  end\n  it do\n    is_expected.to contain_user('$apache::params::user').\n             with({\"ensure\"=\u003e\"present\",\n                   \"gid\"=\u003e\"$apache::params::group\",\n                   \"require\"=\u003e\"Package[httpd]\"})\n  end\n  it do\n    is_expected.to contain_class('apache::service').\n             with({\"service_enable\"=\u003e\"true\"})\n  end\n  it do\n    is_expected.to contain_exec('mkdir $apache::params::confd_dir').\n             with({\"creates\"=\u003e\"$apache::params::confd_dir\",\n                   \"require\"=\u003e\"Package[httpd]\"})\n  end\n  it do\n    is_expected.to contain_file('$apache::params::confd_dir').\n             with({\"ensure\"=\u003e\"directory\",\n                   \"recurse\"=\u003e\"true\",\n                   \"purge\"=\u003e\"$purge_confd\",\n                   \"notify\"=\u003e\"Class[Apache::Service]\",\n                   \"require\"=\u003e\"Package[httpd]\"})\n  end\n  it do\n    is_expected.to contain_concat('$apache::params::ports_file').\n             with({\"owner\"=\u003e\"root\",\n                   \"group\"=\u003e\"root\",\n                   \"mode\"=\u003e\"0644\",\n                   \"notify\"=\u003e\"Class[Apache::Service]\",\n                   \"require\"=\u003e\"Package[httpd]\"})\n  end\n  it do\n    is_expected.to contain_concat__fragment('Apache ports header').\n             with({\"target\"=\u003e\"$apache::params::ports_file\",\n                   \"content\"=\u003e\"template(apache/ports_header.erb)\"})\n  end\n  it do\n    is_expected.to contain_exec('mkdir $apache::params::mod_dir').\n             with({\"creates\"=\u003e\"$apache::params::mod_dir\",\n                   \"require\"=\u003e\"Package[httpd]\"})\n  end\n  it do\n    is_expected.to contain_file('$apache::params::conf_dir/$apache::params::conf_file').\n             with({\"ensure\"=\u003e\"file\",\n                   \"content\"=\u003e\"template($conf_template)\",\n                   \"notify\"=\u003e\"Class[Apache::Service]\",\n                   \"require\"=\u003e\"Package[httpd]\"})\n  end\nend\n\n```\n\n## About the test suite\nAt this time the test suite that is automatically generated is very basic.  Essentially it just creates a test for every resource not in a code block with the exception of conditional code blocks.  While this might be all you need, the more complex your code is the less retrospec will generate until further improvements to the generator are made.\n\nHowever, one of the major stumbling blocks is just constructing everything in the spec\ndirectory which retrospec does for you automatically.  Its now up to you to further enhance your test suite with more tests and conditional logic using describe blocks and such.  You will notice that some variables are not resolved. Currently this is a limitation that I hope to overcome, but until now its up to you to manually resolve those variables prefixed with a '$'.\n\nExample:\n\n```ruby\nshould contain_file('$::tomcat::params::catalina_home').\n             with({\"ensure\"=\u003e\"directory\",\n                   \"owner\"=\u003e\"$::tomcat::params::user\",\n                   \"group\"=\u003e\"$::tomcat::params::group\"})\n\n```\n\nFor now you will probably want to read up on the following documentation:\n\n* [Puppet Rspec](http://rspec-puppet.com)\n* [Puppet spec helper](https://github.com/puppetlabs/puppetlabs_spec_helper/blob/master/README.markdown)\n\n\n## How Does it do this\nBasically Retrospec uses the puppet lexer and parser to scan your code in order to fill out some basic templates that will retrofit your puppet module with unit tests.\n\n## Overriding the Templates\nThere may be a time when you want to override the default templates used to generate the rspec related files. By default retrospec will clone these [templates](https://github.com/nwops/retrospec-templates) and place inside the default or specified template directory.  \n\n```shell\n-t, --template-dir=\u003cs\u003e        Path to templates directory (only for overriding Retrospec templates) (default: /Users/cosman/github/retrospec-templates)\n-s, --scm-url=\u003cs\u003e             SCM url for retrospec templates (default: git@github.com:nwops/retrospec-templates.git)\n-b, --branch=\u003cs\u003e              Branch you want to use for the retrospec template repo (default: master)\n\n```\n\n### Environment variables to set template defaults\nRETROSPEC_PUPPET_SCM_URL  # set this to auto set your scm url to the templates\nRETROSPEC_PUPPET_SCM_REF (from version 1.6.0)  # set this to auto checkout a particular branch (only works upon initial checkout)\nRETROSPEC_PUPPET_SCM_BRANCH :same as RETROSPEC_PUPPET_SCM_REF. Use this in version before 1.6.0. As of this version, RETROSPEC_PUPPET_SCM_REF takes precedence.\n\nAfter running retrospec, retrospec will clone the templates from the default template url or from whatever you set to the templates path.  If you have already created the erb file in the templates location, then retrospec will not overwrite the file as there will be a SCM conflict. You can use multiple template paths if you use them for different projects so just be sure the set the correct template option when running retrospec.  `retrospec -t`\n\nThe default user location for the templates when not using `retrospec -t` variable is ~/.retrospec/repos/retrospec-puppet-templates\n\nExample:\n`--template-dir=~/my_templates`\n\n## Beaker Testing\nBeaker is Puppetlabs acceptance testing framework that you use to test puppet code on real machines.  Beaker is fairly new and is subject to frequent changes.  Testing patterns have not been established yet so consider beaker support in puppet-retrospec\nto be experimental.\n\nIf you wish to enable the creation of beaker tests you can use the following cli option.  By default these acceptance tests are not created.  However at a later time they will be enabled by default.\n\n`--enable-beaker-tests`\n\nI am no expert in Beaker so if you see an issue with the templates, acceptance_spec_helper or other workflow, please issue a PR.\n\n## Troubleshooting\nIf you see the following, this error means that you need to add a fixture to the fixtures file. At this time I have no idea what your module requires.  So just add the module that this class belongs to in the .fixtures file.\n\nSee [fixtures doc](https://github.com/puppetlabs/puppetlabs_spec_helper#using-fixtures) for more information\n\n```shell\n8) tomcat::instance::source\n     Failure/Error: it { should compile }\n     Puppet::Error:\n       Could not find class staging for coreys-macbook-pro-2.local on node coreys-macbook-pro-2.local\n     # ./spec/defines/instance/source_spec.rb:34:in `block (2 levels) in \u003ctop (required)\u003e'\n```\n\nIf you see something like the following, this means your current module is using a much older version of Rspec.  Retrospec uses Rspec 3 syntax so you need to update your rspec version.  If you have tests that using older rspec syntax, take a look\nat [transpec](https://github.com/yujinakayama/transpec)\n\n```shell\n   103) apache::vhost\n        Failure/Error: is_expected.to contain_file('').\n        NameError:\n          undefined local variable or method `is_expected' for #\u003cRSpec::Core::ExampleGroup::Nested_59:0x007ff9eaab75e8\u003e\n        # ./spec/defines/vhost_spec.rb:103:in `block (2 levels) in \u003ctop (required)\u003e'\n\n```\n\nIf your tests will not run after running retrospec. Your spec_helper, Rakefile and Gemfile may not be compatible with the pre-defined templates.  Just delete these files and re-run retrospec to recreate them.  Add back any modifications you might have had.\n\n## Running Retrospec Tests\nPuppet-retrospec tests its code against real modules downloaded directly from puppet forge.\n\nTo run a clean test suite and re-download you must run with environment variable set\n```\nRETROSPEC_CLEAN_UP_TEST_MODULES=true bundle exec rake spec\n```\n\nOtherwise to save time we skip the removal of test puppet modules therefore we don't re-download\n```\nbundle exec rake spec\n```\n\n## Understanding Variable Resolution\nBecause the code does not rely on catalog compilation we have to build our own scope through non trival methods.  Some variables will get resolved while others will not.  As this project progresses we might find a better way at resolving variables.  For now, some variable will require manual interpolation.\n\n### Variable Resolution workflow.\n\n1. load code in parser and find all parameters. Store these parameter values.\n2. Find all vardef objects, resolve them if possible and store the values\n3. Anything contained in a block of code is currently ignored, until later refinement.\n\n## Puppet 4.x Support\nAs of 1.0.0 Retrospec Puppet provides full support for code written against the 4.x/future parser.\nIf you have 3.x code the 4.x parser may throw errors instead of deprecation warnings.\nIf you do not wish to convert your 3.x to 4.x code yet, you will need to use the puppet-retrospec\nversion \u003c 1.0.0\n\n\n## Ruby Support\nCurrently this library only supports ruby \u003e= 1.9.3.  Since we vendor Puppet 4.5.x you need to have\na supported ruby version that puppet 4.5 supports which.  \n\n## Paid Support\nWant to see new features developed faster?  Contact me about a support contract so I can develop this tool during\nthe day instead of after work.  contact: corey@nwops.io\n","funding_links":[],"categories":["Puppet Tools"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnwops%2Fpuppet-retrospec","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnwops%2Fpuppet-retrospec","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnwops%2Fpuppet-retrospec/lists"}