Cypress tests organizing (or any e2e/ui tests)
Nowadays cypress is quite a hype technology (I am saying this in Fall 2020, everyone knows how rapidly js world can change ;))
"Cypress is a next generation front end testing tool built for the modern web."
I had some experience with Behat and other types of tests like unit/integarational, but today I will tell you about e2e.
When I wrote Behat tests I didn't think a lot about how to structure my test cases in a maintainable way. This led me to the antipattern called "Single-Layer Architecture".
Extending such tests quickly becomes a mess and tends to become an ineffective work:
- You can't focus on business logic, you always need to remember low-level details to introduce a new step definition
- Your low-level solutions are often duplicated, and you even don't notice that
- Changing testing framework means rewriting or updating all step definitions!
Fortunately there is an approach which is very easy to follow and which mitigates mentioned issues.
How games (or any pet projects) should never be developed
This story is about wasting time and life. It is about Attraction Wars.
Attraction Wars is an online browser game I developed in my free from job time.
I am surrounded with "success stories". But very few new projects (or startups if you want) succeed. According to the different sources, it is less than 10%, I more believe sources which say that it is even less than 1%.
Of course, it dramatically depends on which stage startup was accounted for this statistics... But this story is not about it. I just feel that I should write "story of NOT success", just to dilute all that success stories with other fairy tale.
Honestly I think that history of Attraction Wars development is an example of how games (or any pet projects) should never be developed.
However it teached me a lot, including technologies and outlook, so I hope this experience will be useful for someone. Or only for me as reminder.
But if you are interested of this deep dive to cave, then please go ahead.