search

leeola / appaid.kdapp

A Koding App for Faster Koding App Development
MIT License
1 stars 0 forks source link

0.2.0 Discussion #1

Open leeola opened 11 years ago

leeola commented 11 years ago

Questions, comments, or desires for the testing-oriented 0.2.0 release should be posted here.

stefanbc commented 11 years ago

How about a clear/close button for the inception cases?

leeola commented 11 years ago

Good idea! though i would classify that as a 0.1.0 feature enhancement, i'll open a ticket for it, thanks :)

Until i add that, to work around this you can simply re-load the root app. :)

leeola commented 11 years ago

@cliffrowley Do you have any preferences on a Browser testing framework? I'd prefer something not too opinionated (the framework itself), letting people work how they like.

cliffrowley commented 11 years ago

Personally, I use Capybara, but it's Ruby so I'm not sure how useful it'd be here unless you write your tests in Ruby too (e.g. minitest or rspec).  Capybara will allow you to abstract the browser, supporting Selenium, ChromeDriver, QTWebKit, or Poltergeist - or actually any browser you want with a little (not much) work.  It's pretty good.

I don't mind helping put something together.

leeola commented 11 years ago

Well for starters, i think we need to answer the following:

Do we want api/framework only tests? Or do we want browser emulation-like tests (Selenium/etc). I lean towards the first, but if we can support both nicely, without making this heavy, clunky, unfriendly, and basically bad, then i'd like to support both.

I tend to dislike a lot of browser automatic tools, and prefer AngularJS-like approaches with more mock focused/supportive APIs, but that's not denying the usefulness of real browser automation.

I do think ideally, we will use a JavaScript-language framework, as CoffeeScript(Or JS) is what the majority of KDApps will be written in

cliffrowley commented 11 years ago

Do we want api/framework only tests? Or do we want browser emulation-like tests (Selenium/etc). I lean towards the first, but if we can support both nicely, without making this heavy, clunky, unfriendly, and basically bad, then i'd like to support both.

I tend to dislike a lot of browser automatic tools, and prefer AngularJS-like approaches with more mock focused/supportive APIs, but that's not denying the usefulness of real browser automation.

No idea, you asked about browser based testing, I told you what I use ;-)

leeola commented 11 years ago

No idea, you asked about browser based testing, I told you what I use ;-)

Well when i said browser based, i meant.. can run in browser. That's the only location for the API, so even if we have framework only tests, it's still browser based. I think there are two different types, which i pointed out. Simple JS ones that are generally designed for Node, but also run in the browser, don't emulate real browser junk. Selenium/etc are in another category haha.

Anyway, i figured you would have an opinion on the choice between the two :)

leeola commented 11 years ago

Also, email replies are horrible at quoting. lol.

cliffrowley commented 11 years ago

I guess don't really an opinion on a client side testing framework because I don't really do it - I'm a server side guy with an overlap in front end tech when it comes to web stuff :-)