BDD Internals

This section documents the internal working of the BDD code framework. The audience for this section is for developers who are extended the BDD system and want to learn more about how it operates.

Information about creating tests and tests should be included in other parts of the guide.

Logging (bdd_utils:log)

The BDD system has a logging utility that is managed from the Configuration file.

The core logging call is bdd_utils:log(Config, Level, Message, Data). Shortcuts have been created, but are not recommended because they do not leverage ability for users the change the logging levels! The short cuts are: log(Level, Message, Data), log(Message, Data), and log(Message) where the assumed Level is info

The logging system offers several levels:

  1. true - always show the message
  2. puts - always shows for debugging info that should be removed and not left in the code
  3. dump - the lowest level of in-code statement used to output items that take up multiple lines
  4. trace - very verbose but helps trace entry of routines (do NOT dump objects using trace!)
  5. debug - general information used for debugging problems and common issues
  6. info - useful data about normal operations
  7. warn - actions that are not normal and may require investigation
  8. depricate - helps find class that have been depricated
  9. custom - you can define your own levels (e.g.: using your name, mascot or martian crater) as long as you remember to include it in the configuration list.

To set the log level from the Erlang command prompt, use the helper ‘bdd_utils:log_level(debug)’ or other level. The log_level command will include the correct items. Users can manually set the logging level by including the desired level in the configuration. Levels must be added explicitly! There is no assumption of inclusion: if you want trace and warn then you need to add both to the logging list.

The legacy debug methods are depricated and should be avoided!

You can use the log information in two ways

  1. modify the configuration file when running tests (applies to all tests)

  2. use bdd:debug(config, feature, scenario_id#, [log, level, list]). to call a single scenario with custom logging. If you omit the list then it will default to [puts, debug, info, warn]

    Log messages can be very verbose! Generally, running just 1 scenario is enough information for debugging.

Logging for Titles

The information shown during test runs is also generated by the logging but managed by the “titles” config.

The log titles are

  1. Feature Titles
  2. header - BDD general information
  3. result - Results from a run
  4. feature - Feature introduction
  5. Scenario Titles
  6. pass - scenario passed
  7. fail - scenario failed
  8. skip - scanario skipped
  9. step - same as pass
  10. step_pass - details about step passed (used when failed)
  11. step_fail - defails about step failed (used when failed)