/ffaker

Faker refactored. Cleaner. Faster.

Primary LanguageRubyMIT LicenseMIT

Build Status Code Climate

ffaker

Gitter

ffaker is a rewrite of faker.

Usage

require 'ffaker'

FFaker::Name.name       #=> "Christophe Bartell"
FFaker::Internet.email  #=> "kirsten.greenholt@corkeryfisher.info"

See more →

ffaker vs faker

The faker and ffaker APIs are mostly the same, although the API on ffaker keeps diverging with its users additions. In general, the only difference is that you need to:

gem install ffaker

and then

require 'ffaker'

Why ffaker?

ffaker is a fork of faker, and was initially written in an effort to speed up a slow spec suite. Since those days faker has also been rewritten and the "speed" factor is probably irrelevant now. Bear in mind, if your spec suite is slow, chances are the generation of random data will probably not account for much of the run time.

Nowadays the code bases have diverged enough to make the two projects truly different: since ffaker creation, a lot of new API methods have been added through the generous contributions of people all over the world.

Hopefully some day faker and ffaker will join forces!

Contributors

A lot of people have contributed to ffaker. Check this list.

If you want to add new modules or localization data, use one of the directories for data files (or create a new one!).

const_missing is overriden for Faker modules, so if you try to use a constant that is not defined in the module, the override will look for a data file matching the name of the constant. E.G.: the first time someone accesses FFaker::Name::FIRST_NAMES, a const of that name will be set with data from ffaker/data/name/first_names.

Using the same random seed as your tests

To get repeatable results in Minitest or Rspec, follow these instructions.

TODO

  • Even though the API is pretty simple, better rdoc documentation would not hurt.
  • Put all modules under their respective languages (E.G. EducationUS instead of just Education)

Note on Patches/Pull Requests

  • Fork the project.
  • Make your feature addition or bug fix.
  • Add tests for it. This is important so I don't break it in a future version unintentionally.
  • Commit, do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)
  • Send me a pull request. Bonus points for topic branches.

Copyright

Copyright (c) 2013 Emmanuel Oga. See LICENSE for details. Copyright (c) 2007 Benjamin Curtis