Testing Code Diary Entries

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job.

• A failing test is probably right
• All database types must be separate in each ENV
• Authorization requires at least three tests
• Beware of mock once
• Browser tests generally need full url not paths
• Cache build process based on the lock file instead of dependencies
• Do not confuse object and content equality
• Do not use numerical step ids
• Ensure you test against binary data if appropriate
• ENV variables are a major cause of test failures on ci
• Finder logic needs to be tested against two records minimum
• Ideally test on a third party machine spinner up
• If something is numerical in nature always unit test
• In browser tests assume state will get out of sync with respect to your test
• In gui testing you might need to slow input down to human levels
• In integration tests allow clicking on labels
• Joins must be tested with at least three records
• Let block affects mocking in before block
• Limit the amount of messages you send to objects
• Make it impossible to deploy if tests fail
• Mocks fail when there are independently started processes
• Never make your queues synchronous in your integration tests
• Pages loaded in before scripts outside describe block will be missing any local let data
• Realize that switches on production environment are untestable
• Remember tests are just regular code
• Run your tests daily otherwise your lock in difficult to remove errors
• Start broad brushed then narrow
• Test both with data and from a blank slate
• Use canary tests for dependencies
• Watch for persistent caches between test runs
• Watch out for brittleness due to forms that vary depending on geolocation
• Watch out for testing against multiline strings
• When freezing time you must sync this between the server and the client