2017/Berlin/testing

From IndieWeb

testing was a session at IndieWebCamp Berlin 2017 discussing software testing while developing indieweb sites and tools.

Notes archived from: https://etherpad.indieweb.org/testing


IndieWebCamp Berlin 2017

Session: testing

When: 2017-11-04 17:00

Participants

Notes

  • webmention.rocks
  • testing 3rd party services is tricky - what if e.g. changes their APIs
  • you should have a staging server
  • you even get problems if you're using a subdomain


  • mostly manual testing
  • posseing to twitter

- dm and use the name of a second account - because it came from sms

  • automated testing

- cron job to send webmentions

  • functional testing if you use your own system

-

  • components are tested very well - e.g. webmention.rocks, indieauth.rocks
  • integration tests
  • automated testing is super useful but super difficult
  • a lot of what we are doing is experiments at this point
  • we don't know exactly what we're writing in advance, so we can't always write tests first
  • there are lots of debugging tools
  • bug-driven development
  • external resource testing tools (i.e. humans) - peer 2 peer testing
  • tests are good for regression testing
  • visual regression testing - sometimes manually , sometimes with screenshot comparison tool
  • jeena - works in automobile where testing is important

- still a lot of manual labour in this, tryin* cron job to send webmentionsg to automate more

  • testing might be of beneft when we get to the gen 3 level
  • writing tests in boring, writing use cases is boring
  • where would the place be to start for writing automated tests?

- look at the dependencies of what your site is working on - look at the libraries, and add tests to those components if needed - then start with the integration tests

- manual of the components already have good tests

  • who tests the parsers?

- the developers of each parser - report them as github issues

  • date parsing is difficult
  • whitespace handling
  • automatic testing - don't test the tools, only test the code
  • in theory, it would be great to stub all of the libraries - but that's a lot of work
  • automatic testing doesn't necessary match the pragmatic approach of the indieweb
  • it's usually two guys playing around and seeing if something is interesting
  • it's when a 3rd person comes along that we realise maybe we need some docs
  • there was an issue with windwind when a dependency hadn't been pulled in
  • do we have a website that does everything that we can test against?
    • in many ways wordpress is the best implementation so far
    • someone recently open sourced their site with all of the implementations
    • thinking about e.g. glitch or neocities as a place to setup a testing backend
  • hacking the .rocks sites to add an api would probably be merged if someone worked on it