@xenetics There’s no difficulty in setting the unit and e2e testing. Currently don’t want to release a half baked testing until I figure out a good way on making components which use VueRouter testable. That would be the last milestone.
Martin last edited by
Is anyone already writing unit tests for at least some basic methods/functions, in a customized Quasar 2.x project? It’s not my top priority right now (still in alpha stage) but at some point I’d like to switch to test driven dev. It’s a scary thought to have my app on a lot of phones without any testing.
MusicForMellons last edited by
boriscy last edited by
Same here, need unit testing and e2e.
Will see what I can do. Time is the only problem
dlevin last edited by
What are the issues you’re running into with vue-router? I’m currently trying to set up testing similar to what is generated by the vue-cli webpack template but am struggling…
Unit testing and e2e testing is really necessary for such a great framework as Quasar.
MusicForMellons last edited by
For e2e might consider Testcafe (in place of Nightwatch):
complete test harness
flexible selector system
smart assertions with retry policy
leon last edited by
Yes, im starting use Testcafe
Its like convention over configurations, and i love it.
Very easy. All you need
Adding to @MusicForMellons
- screenshot fail steps
- no need extra code, ex: wait doom element …
LaurentPayot last edited by LaurentPayot
I evaluated several e2e testing solutions and I ended choosing Codecept over Testcafé for its conciseness. Nightmare (electron) integration is also a nice feature.
Feature('CodeceptJS Demonstration'); Scenario('submit form successfully', (I) => I.amOnPage('/documentation') I.fillField('Email', 'email@example.com') I.fillField('Password', '123456') I.checkOption('Active') I.checkOption('Male'); I.click('Create User') I.see('User is valid') I.dontSeeInCurrentUrl('/documentation') });
Anyway Quasar should let us chose whatever e2e testing solution we want, as e2e testing should be totally decoupled from the implementation.
Qusar really needs support for typescript and unit testing.
I started a github repo where I try to integrate both but I need help.
There are 2 branches:
master : contains support for typescript and that works stable.
unittests: still is still experimental and that’s the place where I need help.
Please make PR’s so that we can get unit testing working.
@paul There are many people interested in Typescript full support. I’ll make a team for this and you along whoever else is interested can participate in making an official Typescript support repo. I’ll set everything up, but after I finish up v0.14. Anyone interested in Typescript drop me an email pls. Thanks!
Should we not “just” have a
quasar.d.tsfile (I have one in my project, that could be a good start that i could add in a PR).
Making Quasar a pure TS project would be fun, but I am not sure this would benefit many at the moment.
@rstoenescu Thanks for that. Keep us informed. Typescript is the way go for serious js work.
Typescript is the way go for serious js work.
To manage a large amount of source code base, you need all the help you can get.
By using typescript you get a language that looks and feels like JS, but with lovely static type checks, templates and nice transpiling abilities.
I will recommend it any day, even for small projects, it is really worth it !
LaurentPayot last edited by
I didn’t mean to make this a “static/ dynamic typing” war, but let’s look at those static typing advantages.
Better design - being forced to think about the types of values in your software up front can push you towards cleaner, more logical solutions. (I say can - it’s still possible to design really bad code…)
Better compile time checking - static typing can enable more errors to be caught at compile time. This is a huge advantage, and is arguably the best thing about statically typed languages overall.
Auto-completion - static typing can also give more information to the IDE so that auto-completion of code or documentation lookup is more effective.
Discourages hacks - you have to keep type discipline in your code, which is likely to be an advantage for long term maintainability.
Type inference - in some languages (e.g. Scala) this can get you many of the conciseness benefits of dynamic languages will still maintaining type discipline.
Thanks @s-molinari that saved a lot of arguments As @LaurentPayot say it is sometime a question of taste, but I really find static typing a bit more useful than just the subjective value (I am working on my 3. large JS project now :-))
Typescript grows on you (on me at least), the more you trust (and understand) it the more it will and can help you, but you can start out not using types at all for a start and go from there.
I know that the static typing idea (regardless of language) at first can feel like a straitjacket (it will need initial attention, and start pick at you code), but when the compiler starts finding dumb bugs that saves you hours or even days of debugging, it feels more like an old friend, that help you on your way, but … it also tells you the truth strait away (like old friends are supposed to)
Hmm…my post is not what I wanted to post. Buggers. At any rate, I wanted to ask, how about Flow? Seems like it is a step above TS since it can help with type inference at first and adding all the type definitions can be done later or as we need it.