<commit_before>Testing data

- use in-memory database instead of on-disk database
- use a fake database object
- use fixture data (not recommended; it's brittle)
- use factories (more flexible than fixtures, but still slow)
- use test doubles (mocks, stubs, spies, etc)

RSpec documentation
- avoid rspec.info; it is waaaaay out of date
- Use https://www.relishapp.com/rspec/ to get an idea of what you can do
  - Core: covers describe, it, before, shared contexts, etc
  - Expectations: equality, identity, "truthiness and existentialism" :D
  - Mocks: stuff to do with test doubles
- Use RSpec's RDoc to find details about how a specific method works
  - http://rubydoc.info/gems/rspec-core/

KINDS OF TESTS
- Unit tests generally have these characteristics:
  - fast
  - isolated (from file system, from database, from I/O, ...)
  - tend to use doubles (mocks and stubs)
- Integration tests
  - tend to set up scenarios, invoke code, and verify state
    - see also: blog post: "Mocks Aren't Stubs" by <NAME>
  - "short-span": only testing a few interacting objects, e.g., a subsystem
  - "full stack": the whole enchilada
  - May still focus on a specific scenario or edge case
- Acceptance test
  - *might* be written by a user (or at least a product manager), if you're lucky
  - *should* be readable by them
  - describe some scenario in terms that a user cares about
    - ex:  "When I update my profile"
      versus "When I click on the 'my profile' link, go to the profile page, and enter 'Sam' in the first name field... blah blah blah"
<commit_msg>Add link to TDD fizzbuzz<commit_after>Testing data

- use in-memory database instead of on-disk database
- use a fake database object
- use fixture data (not recommended; it's brittle)
- use factories (more flexible than fixtures, but still slow)
- use test doubles (mocks, stubs, spies, etc)

RSpec documentation
- avoid rspec.info; it is waaaaay out of date
- Use https://www.relishapp.com/rspec/ to get an idea of what you can do
  - Core: covers describe, it, before, shared contexts, etc
  - Expectations: equality, identity, "truthiness and existentialism" :D
  - Mocks: stuff to do with test doubles
- Use RSpec's RDoc to find details about how a specific method works
  - http://rubydoc.info/gems/rspec-core/

KINDS OF TESTS
- Unit tests generally have these characteristics:
  - fast
  - isolated (from file system, from database, from I/O, ...)
  - tend to use doubles (mocks and stubs)
- Integration tests
  - tend to set up scenarios, invoke code, and verify state
    - see also: blog post: "Mocks Aren't Stubs" by <NAME>
  - "short-span": only testing a few interacting objects, e.g., a subsystem
  - "full stack": the whole enchilada
  - May still focus on a specific scenario or edge case
- Acceptance test
  - *might* be written by a user (or at least a product manager), if you're lucky
  - *should* be readable by them
  - describe some scenario in terms that a user cares about
    - ex:  "When I update my profile"
      versus "When I click on the 'my profile' link, go to the profile page, and enter 'Sam' in the first name field... blah blah blah"

--

Possibly also of interest:  https://github.com/geeksam/tdd-fizzbuzz
{'fraction_non_alphanumeric': 0.08299531981279251, 'fraction_numerical': 0.0, 'mean_word_length': 3.3978052126200273, 'pattern_counts': {'":': 4, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 3, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6452471', 'n_tokens_mistral': 976, 'n_tokens_neox': 924, 'n_words': 463}