• Hey again,

    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.


  • Admin

    @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.

  • 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.

  • Same here, need unit testing and e2e.

  • Admin

    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):
    easy install
    complete test harness
    javascript ES2016 with (async/await)
    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 …
    • fast

  • 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.fillField('Email', 'hello@world.com')
      I.fillField('Password', '123456')
      I.click('Create User')
      I.see('User is valid')

    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.

  • Admin

    @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.ts file (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 !

  • @druppy static vs dynamic typing is really a matter of personal preference. Here is a good list of advantages/drawbacks.

  • 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) 🙂

    As for me, as soon as a peace of code grow to more than 300 lines, I start wishing for types regardless of this being bash, python or javascript, this could be personally taste or my lake of huge amount of short term memory, but regardless of the reason static types helps me being productive.

Log in to reply