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', 'firstname.lastname@example.org') 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 !
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.
PS: if you want to start another war, I proudly indent with TABS
LaurentPayot last edited by LaurentPayot
To go back to the testing subject, just like @Martin I use Firebase . Because this is a serverless architecture I simply use Mocha with Firebase admin sdk for my Firebase-related unit tests: user CRUD and so. It’s a nice combo with codeceptjs for e2e testing.
I do not test the view layer (Vue) because I don’t think it’s worth the (huge) effort.
@LaurentPayot - yeah. I am not really begging here at all to get any type system going. In fact, I am more like you in my thinking. To me a type system is a crutch for the “not-so-careful” or “not-so-experienced” or those afraid of JS’s dynamic capabilities and them being so odd compared to stricter typed languages. Type checking can, however, contribute to what many say is a better developer experience. I personally haven’t used TS or Flow enough to say “yup. That is correct.” And, good design, programming and testing can offer a nice developer experience too.