Skip to content

Instantly share code, notes, and snippets.

@sebastiandero

sebastiandero/testing.md

Last active November 2, 2021 19:16
Show Gist options
  • Save sebastiandero/ded46111e99da61a19002bfd24130b53 to your computer and use it in GitHub Desktop.
Save sebastiandero/ded46111e99da61a19002bfd24130b53 to your computer and use it in GitHub Desktop.
Download ZIP
Coding Guidelines
Raw
testing.md

Testing

At <...>, we practice Test Driven Development. We expect you to write a test before you start working on a piece of functionality. We want at least one test for every small piece of functionality that you write.

Tipps

  • Do not write tests for functions or methods, write tests for functionality
  • In a unit test you should be testing one unit of functionality, not a class or function. If you need 3 classes or functions to write a meaningful test for the functionality, then that's your unit.
  • Use the lowest class of test you can, and the highest you have to: Unit → Integration → E2E. High test classes (for example E2E) help you test functionality instead of writing coverage tests. (high mock count, duplicated implementation, has to be adapted every time you change the functionality)

How to know if you are using the right type of test (Smells):

  • My test needs a lot of mocks → you need a higher test class
  • My test is duplicating the implementation → you need a higher test class
  • It takes me minutes to run the tests for every small change → you need a lower test class
  • My tests are very flaky → you need a lower test class

Good Tests

  • Easy to read, are semantic, descriptive, concise
  • Don't use a lot of mocking
  • Treat the functionality as an idempotent function; data in → data out
  • Test edgecases and security requirements

Further Reading

  • Growing Object-Oriented Software Guided by Tests
  • Test Driven Development by Example
  • CodeCademy courses on TDD
Raw
values_principles.md

Values & Principles

Customer Centric

  • Before thinking of any solution, ask yourself:
    • What problem are we solving?
    • For whom are we solving it?
    • What are their motivations behind solving that problem?
    • How do we know they really have this problem?
  • Keep the holistic story in mind when developing solutions.

More with Less

  • "I didn’t have time to write you a short letter, so I wrote you a long one." - Mark Twain
  • To remain scalable and sustainable we need to use the least complex solution to any type of problem we need to solve.
  • Before you think about what you can add to fix your problem:
    • What could I stop doing / remove to fix my problem?
    • Is this really my Problem? (5 Whys)
Raw
working_together.md

Working Together

Continuous Integration

Make sure to merge your changes at least once a day. If you become too far desynced, the integration effort will be big, which will cost us valuable time. It also forces you to work in small batches, ****which reduces the time you will spend debugging code. As you are required to do Test Drivent Development working in small batches should not be an issue for you, as you are working in tiny piece by piece batches of "red → green → refactor".

Pull Request Reviews

When Opening

  • Give people enough context around your pull request, so that they know what this pull request is trying to achieve.
  • Make sure your code is concise, easy to understand and follows the Clean Code principles
  • Go through the list below to make sure that there are no unecessary feedback loops

When Reviewing

When reviewing a pull request keep the following in mind:

  • Is there at least one test for every small piece of functionality that is included?
    • Are edge cases considered
    • Are security requirements tested for?
  • Is this code ready to be released or should it be behind a feature flag?
  • Imagine you would have to change something in this code, how much would you hate the author?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment