Arpit MohanTL;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
