Hi! Thanks for the quick reply. Just to clarify, you recommend porting the vue1 template to vue2 then? (while using webpack1) or using the latest, and porting the test setup from th vue1 template?
What are the main difficulties you foresee in adding testing? Karma compatibility with Webpack 2?
IF you can point me in the right direction I am interested in setting up testing and hopefully contributing. I want to use quasar for a internal company project, but no way to test is a deal breaker.
@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.
Same here, need unit testing and e2e.
Will see what I can do. Time is the only problem
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.
For e2e might consider Testcafe (in place of Nightwatch):
complete test harness
flexible selector system
smart assertions with retry policy
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!
druppy last edited by
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.
s.molinari last edited by
Typescript is the way go for serious js work.
druppy last edited by
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
s.molinari 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.