After playing with codewars.com for some time I noticed lack of similar resource for QA. So I built some basic testing assignments and inquired whether a QA-flavoured spinoff would be possible.
The conclusion is "no" and main reasons are:
- a typical Codewars problem is way easier to solve in online editor than testing solution
- some QA frameworks tend to involve boilerplate code
- validating a test would require a human code review, unlike predefined tests in Codewars
- complexity will increase with dependencies like unit test frameworks or BDD support
- clever few-liners are hardly possible (not a required feature, but highly educative)
However, there was some residue left after this failed inquiry. I named it QAbrica and put on GitHub - https://github.com/jiwanski/qabrica.
It is a flat collection of QA tasks and solutions. The assignments posted so far, five in total, were created when trying to envisage Codewars for testers.
Current testing tasks are of two types:
- trivial math problems, implemented as simple Python code
- web tasks, best solved using Selenium
Due to my juniority, only few solutions are available and some might need refactoring. Current statuses are:
- solved (☑), using Python with testing frameworks or Robot Framework or pure Python
- irrelevant (-), for example, non-BDD task won't require behave or lettuce
- not implemented (x), like Robot Framework not supporting Gherkin data tables
- waiting to be solved (☐)
| source | feature | task | Python | Robot Framework | Python pytest | Python unittest | Python behave | Python lettuce |
|---|---|---|---|---|---|---|---|---|
| web | scroll with execute script | count flags in eBay popup | ☐ | ☐ | ☐ | ☑ | - | - |
| Python | parameterization | harshad numbers | ☐ | ☐ | ☑ | ☐ | - | - |
| Python | BDD (scenario outline) | multiples of 3 and 5 | - | ☑ | - | - | ☑ | ☐ |
| web | string with HTML entity | title with HTML entity | ☑ | ☑ | ☑ | ☐ | - | - |
| Python | BDD (data tables) | validate triangle | - | x | - | - | ☐ | ☑ |
A generic structure is more or less like this:
| path | feature |
|---|---|
| task.md | task description |
| [robot] | Robot Framework solution |
| robot/docs.md | how to run test, sample output, notes |
| robot/test/solution.robot | actual Robot test |
| [python_selenium] | Python solution (no framework) |
| python_selenium/docs.md | how to run test, sample output, notes |
| python_selenium/test/solution.py | actual Python test |
| [python_pytest] | Python solution (pytest) |
| python_pytest/docs.md | how to run test, sample output, notes |
| python_pytest/test/conftest.py | pytest configuration script |
| python_pytest/test/test.py | actual test |
| python_pytest/test/pytest.ini | pytest INI file |
| step | action |
|---|---|
| examine problem | read problem/task.md |
| examine chosen solution | read problem/some solution/docs.md |
| run test | execute command from docs.md |
| examine test code, refactor, etc. | analyze problem/some solution/test |
| (optional) create own solution | develop test code and docs in problem/my solution |
Current structure is enough to populate with hundreds of examples and extend with other frameworks/languages.
Unfortunately, I am too busy finding a job now to guarantee steady growth of this collection, unless my next occupation is somehow related to introductory test automation.