Viki HTML5 Player — Tests
When started this project, one thing is in my goal is having tests to cover most of it. Few reasons, it has to automate because this project will need to run on multiple platforms especially on mobile and with only few QA. It won’t work. Also I want to see can front-end project like this have tests and what would it will be because in the past, I don’t have much success with tests on front-end project that much.
So these are few things I learn from the start to handover
- I started with Karma and Mocha, It was my combination I alway choose in that time. Karma is very easy to configure because of documentation and many supported modules. However, it’s not a good choice when you want to see console log and result directly because it’s not showing those in the main browser window. These become more troublesome when running tests on mobile when if you want to see logs, you need to attach it from another browser.
- I started moving to Testem because few issues from Karma that cause specs running in Safari in Saucelabs fail but doesn’t fail in local machine and I cannot find the errors or any meaningful logs to fix it. Testem is a lot more difficult to configure. It doesn’t have much documents compare to Karma and when see the example like this, it almost stop me for using it but in the end, it’s very flexible and more reliable compare to Karma.
- Adding tests in beginning of project feel harder to add because of lack of structure and understanding but when it’s growing to some point, it becomes easier.
- TDD is good to do but it’s ok to add implementation first and adding test later. The goal of testing is maintainability, not design. Only when I have clear idea how this component/behaviour work, then I will adding test first.
- Mobile browser testing is still expensive, it’s slower than desktop (around 3–4 times) and this is just unit-tests. Sometime it’s also fail with unknown errors. These happen on both iOS and Android. (Mobile browser tests are run on Saucelabs)
- Refactor with tests is a lot easier than without tests, this is very obvious I think most people already know. Other thing I realise is when I need to handover project, tests can use for telling me which part that new people don’t understand and need me to guide more when adding new feature/maintaining the project.
- UI Animation/Video playing are the thing that I still cannot find the way to tests, It can test with the beginning state/end state but moving part is still required people to see and tell is it good enough or not.
- Performance, there’s one component that the spec very helpful to tell performance gain, before I use normal DOM to render each block of point in time that has comment in progress bar and with the test, it can show how slow it is and how much faster when I use canvas instead. And this can repeat by just keep running single test to see the result which a lot faster than go to browser and refreshing.
So this is end of this series, and I thought this will deliver before I handover. I probably learn a lot more than this from this project, e.g. how Google IMA works and all hidden flag that I can change (caution: I think if you do this, probably you don’t need google IMA library). However, I already moved to new project 🍭 and pass this one to a good hands. I hope this will guide them more.