BarcelonaJS Feb 2019

Frontend architecture

Speaker: Carlos Villuendas (@carlosvillu) @ Shibsted

  • Web app
    • Sui Theme
    • Site thmee
      • Business Rules
        • SUI components
        • Site components

Hexagonal architecture

A place for everything and everything in one place

Business rules

  • entities and value objects
  • repositories
  • use cases

Bonus tracks

  • stateless
  • much easeier to test

UI components

  • Site components
  • SUI components

Testing

Speaker: Paqui Calabria — @Zurribulle

Opinionated tips 10+1 about test patterns

  • Each test must be independent
  • Sort test from general to specific: When several tests fail, you’ll know that you need to start debugging for the first one
  • Check one thing per test: It’s ok to use more than one expect, but if the title says “and” it will probably end up being hard to maintain.
  • Don’t forget to clean up: Any modification to the environment that a test has made, has to be reverted later to avoid collateral effects. Delete local, storage, reset the database, restore the stubs/spies behaviour….
  • Make a mocks’ library: Mocking is boring, slow and prepetitive. Create a library of mocked objects, services, components, etc that you can access from any test.
  • Asynchronisms are going to fuck you. Big time: Learn to control them as soon as possible, study, practice. https://blog.cloudboost.io/javascript-asynchronous-testing-gotchas-ac7e5c39257
  • Don’t let them “expire”: Do the tests as soon as possible, run them often, and fix them as soon as they fail. You can use CI tools like Jenkins or Travis, git hoks… no tests = no merge
  • Do not obsess about the coverage: The full report is useful to know what we are leaving untested, but in the end it is just a number. https://github.com/FCalabria/coverage_is_a_lie
  • Do not test trivialities: It is badly invested time, and it incresases the maintainance time.
  • There’s life beyound UT: Study the waknesses of the project before blindy implanting unit tests. Another type could be more useful.
  • Set a test limit: Desperate situations require desperate measures. It is also a good argument to convince managers.

Automated testing for non-developers

  • Easier refactors
  • Better understanding of the requirements
  • More robust components
  • Decreases the bug resolution time
  • Docs for other developers
  • CD with fewer bugs

Comments

⬆︎TOP