We believe in test automation, quality and sustainability of code. All of our systems are failsafe for the end users aka gamers. Here’s some of our methods on how we enforce (in a nice way) our tech standards.
Test Automation
Only thing that ensures our product’s quality is testing. We run our tests before every git commit ...
and our CI runs tests on every merge request. We are really proud to be able to assure our customers that when they use Apprien, every single test has been run on Apprien’s every service and every test has passed 100%.
We currently have over 12500 tests written, with even more assertions.
Unit testing vs. Integration testing
My vision about Unit tests is that Unit tests should be completely non-dependant of anything other than the thing you’re testing. So if you’re testing controller’s action, you should mock every single thing it handles, including the database. This makes it so, if someone makes a change in the database migrations, the code itself calculating only numbers for example. Will behave as it should.
Continuous Integration (CI)
There are multiple events that trigger our CI’s pipeline for each project. We do most of our DevOps on the CI side also, to minimize user error. One of these CI pipeline triggering events is that for example our current Lead Developer Jussi creates a merge request, our CI checks tests and QA. If it goes through, it can be merged after the code review.
Git workflow
We have our own Gitlab set up, which we use for version controlling internal systems. Our public code will (atleast for now) be available on Github. Our git workflow goes so that we use a branch naming convention familiar from JIRA, PROJECT-TASK-description
. Definition of done includes that tests need to be done for the feature wanting to get merged and more. After someone creates a new merge request, our CI checks tests and QA. Then the merge request gets reviewed and if it goes through. It goes to our Staging environment, and from there we release to production.
Pair Programming
While it might cost us more to do pair programming, it helps our coders reach the same skill level faster and more efficiently. This makes sure that our team is always up to date with the big tech stack that we have. Usually we switch pairs around on every daily stand up. If there’s only tasks that everyone can do well, then I try to pair up people by having two coders that know more about different techs. For example Jussi knows a lot about our Game Api backend and Jenna knows a lot about our Apprien dashboard. Pairing them up makes them the perfect combo to complete tasks efficiently.