TL;DR style notes from articles I read today.
Just starting out with test automation? Don't make this mistake
- Whittle down big tests into smaller, shorter ones.
- Don’t wait for the perfect tool, perfect use case, perfect resources. Just start with small automation.
- Smaller tests let you learn faster, contribute sooner, create forward momentum, and get more frequent feedback.
- Let teams focus on learning test automation first before you ask them to focus on complex business logic.
- Automate in small sprints so you can gauge progress, iterate and gather feedback on them from testers, developers and product owners.
Full post here, 5 mins read
10 rules for good API design
- Make the API modular so it is easy to separate experimental pieces from stable ones. Also, make it extensible.
- Use the same style and conventions for each class. Document those conventions and impose them as a required standard for contributors.
- Grow your API by layering new APIs on top of it. Avoid exceeding the current one’s scope.
- Minimize the visible surface area of the API.
- Keep your API portable across OSes and don’t let system concepts leak into it.
Full post here, 4 mins read
“Don’t deploy on Friday” and 3 other “unwritten rules” of software engineering
- Even if you have continuous deployment, Fridays are the worst day to push to master. You only get half a day to fix bugs.
- Keep a couple of backups (for redundancy) of your database, cryptographic keys, configuration files, VM images, images and videos, even imported packages. Git is not enough.
- Wait for complete specs before you begin a build. Avoid assumptions and ask lots of questions, to pinpoint requirements as precisely as possible. Especially, probe corners and edge cases.
- Try to gently stop or prevent unproductive discussions. It is okay to ask for a longwinded discussion to be shelved for more productive work.
Full post here, 4 mins read
Top comments (1)
Easiest way to have a fully modular API with accurate testing is to build microservices with event sourcing and CQRS principles. You can recreate actions and events step by step through your event handlers and listeners for testing and have a complete transactional history through your event store.