Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

formfactor.coffee now tests against real user agents #456

Closed
wants to merge 22 commits into from
Closed

formfactor.coffee now tests against real user agents #456

wants to merge 22 commits into from

Conversation

rdwallis
Copy link
Contributor

No description provided.

@rdwallis
Copy link
Contributor Author

Sorry for the replicated commits, not sure how to keep my branches clean.

@rdwallis
Copy link
Contributor Author

Can someone help me pass the Jasmine tests? The failing code is in formfactor.coffee

@Pacane
Copy link
Contributor

Pacane commented Mar 13, 2014

What kind of help do you need exactly? To make the specs run manually, or to make them pass?

@rdwallis
Copy link
Contributor Author

To make them pass. I think it's probably an issue with the coffeescript I wrote. I'm new to the language.

@Pacane
Copy link
Contributor

Pacane commented Mar 13, 2014

Ok let me look at what you did.

@Pacane
Copy link
Contributor

Pacane commented Mar 13, 2014

I don't know too much about UserAgents, but should these 2:
isMozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10

and

isMozilla/5.0 (iPad; U; CPU OS 4_2_1 like Mac OS X; ja-jp) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5

really be from a tablet browser?

Cause, these are the 2 cases making the build to fail. It's detected as a mobile instead of a tablet.

@rdwallis
Copy link
Contributor Author

Yes they're iPad useragents

@rdwallis
Copy link
Contributor Author

Oh yes I see the mobile in the ua. Perhaps the tests are working correctly and the actual formfactor code is buggy.

@Pacane
Copy link
Contributor

Pacane commented Mar 13, 2014

Yeah most probably.

@rdwallis
Copy link
Contributor Author

Thanks for the help. I think this validates using actual useragents in the tests.

@Pacane
Copy link
Contributor

Pacane commented Mar 13, 2014

A remark though, about CoffeeScript, I think it would be more readable in the tests if you would write them like this (let me know what you think of it) :

desktopUserAgents =
  [
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1664.3 Safari/537.36",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 1083) AppleWebKit/537.36 (KHTML like Gecko) Chrome/28.0.1469.0 Safari/537.36"
  ]

tabletUserAgents =
  [
    "Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10",
    "Mozilla/5.0 (iPad; U; CPU OS 4_2_1 like Mac OS X; ja-jp) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5"
  ]

mobileUserAgents =
  [
    "Mozilla/5.0 (iPod; U; CPU iPhone OS 3_1_1 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Mobile/7C145",
    "Mozilla/5.0 (iPod; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5H11a Safari/525.20"
  ]


describe 'finding from user agent', ->
  describe 'for a mobile device', ->
    for userAgent of mobileUserAgents ->
      it 'should be mobile when userAgent is ' + userAgent, ->
        expect(findFormFactorFromUserAgent(userAgent)).toBe 'mobile'

@rdwallis
Copy link
Contributor Author

Agreed, my for loop was backwards, I'll patch it now.

@rdwallis
Copy link
Contributor Author

Last question. Is it possible to move the userAgent arrays to separate .coffee files? I think they're going to end up quite large.

@Pacane
Copy link
Contributor

Pacane commented Mar 13, 2014

And, out of curiosity, what'll be the scope of this test? How are we going to maintain it? UserAgents strings always change.

@rdwallis
Copy link
Contributor Author

I think we'll never have full coverage but the idea will be to never remove a ua string from the array and then to add strings as we discover them.

My best source for ua strings so far is:
http://techpatterns.com/downloads/firefox/useragentswitcher.xml

I think it updates over time so maybe we can do some kind of diff every month or so and add the new ua's.

I know this sounds like a horrible pain even as I say it.

@Pacane
Copy link
Contributor

Pacane commented Mar 13, 2014

Fair enough. Also, for your question, yes there is a way. It's a bit hacky though, since CoffeeScript's scoping is... somewhat... "special"...

You could create another file, say, userAgents.coffee

window.userAgents =
  [
   ...
  ]

and reference it in your tests

for userAgent of window.userAgents ...

@rdwallis
Copy link
Contributor Author

Ok thanks, I'll separate them out tomorrow.

Also the current code in master incorrectly detects iPad's as mobile instead of tablet so I recommend merging this fix before the next release.

@Chris-V
Copy link
Member

Chris-V commented Mar 14, 2014

I need some details here. So you have UASorter which takes a huge list of User-Agents and populates the coffee script lists? Where does the first list come from?

I'm gonna merge your other PR and wait a little bit for this one, I'll wait for your answers before I do a review :)

@rdwallis
Copy link
Contributor Author

The unsortedUserAgent.json comes from converting http://techpatterns.com/downloads/firefox/useragentswitcher.xml to json.


Each time you run the uasorter program it selects a random useragent from unsortedUserAgent.json

It then prompts the user to supply the formfactor and adds the useragent to the arrays in mobileUserAgents.coffee, desktopUserAgents.coffee, tabletUserAgents.coffee based on the answer.

Then it replaces the useragent in unsortedUserAgent.json with null, so that it won't ask for it again.


When tests are run mobileUserAgents.coffee, desktopUserAgents.coffee and tabletUserAgents.coffee supply useragents to formfactor.coffee which tests to see if the formfactor function interprets them correctly.

@rdwallis
Copy link
Contributor Author

All other commits can wait but commit 439bc52 fixes the formfactor for ipads so it should probably be merged as soon as you're able.

@rdwallis
Copy link
Contributor Author

@Pacane I'm pretty sure I've had a syntax error in formfactor.coffee since replacing the for loops, but the tests didn't fail. I assume because they weren't being run. You might need to add a test to see that formfactor.coffee compiles.

@rdwallis
Copy link
Contributor Author

@Pacane I've added a user agent string to mobileUserAgents which should cause the tests to fail. But the tests pass.

Can you check that window.desktopUserAgents etc is available to the formfactor.coffee code.

@rdwallis
Copy link
Contributor Author

@Pacane tests fail correctly now, so ignore last message. Probably should still add a test to ensure formfactor.coffee compiles.

@Pacane
Copy link
Contributor

Pacane commented Mar 14, 2014

@rdwallis I'm pretty sure that there's a problem though. Usually Jasmine would make a test fail on a compile/syntax error for either CoffeeScript or Javascript. However here, I only get messages like

CoffeeScript Error: failed to compile /home/joel/code/arcbees/GWTP/gwtp-core/gwtp-mvp-client/src/test/javascript/mobileUserAgents.coffee. 
Error message:

SyntaxError: unmatched OUTDENT on line 5 (injected script#8)

In the UI, instead of an actual failure. (UI being the one given by mvn jasmine:bdd)

@rdwallis
Copy link
Contributor Author

Yes if you have a syntax error in the coffee file the tests always pass, so we need to test the coffee files. I'm not sure how though.

@rdwallis
Copy link
Contributor Author

Here's an issue at the jasmine project:

guard/guard-jasmine#112

Edit: looks like it's not the correct project though the error is very similar

@Pacane
Copy link
Contributor

Pacane commented Mar 14, 2014

I think it would be the same problem if we wrote the tests in JS, right? Have you tested it?

@rdwallis
Copy link
Contributor Author

I've added zFinalTest.coffee which can test if the other tests have run.

I named it with a z since tests seem to run in alphabetical order.

This will catch all syntax errors except for the ones in zFinalTest.coffee since it can't test itself.

@rdwallis
Copy link
Contributor Author

If you write the tests in JS then you can catch and fail on exception so we won't have this issue.

@rdwallis
Copy link
Contributor Author

Oh wait we can just make zFinalTest.coffee into a JS file and it should solve our problems.

@Pacane
Copy link
Contributor

Pacane commented Mar 14, 2014

I don't care about coffeescript though, if we can make the whole thing more robust, we can write the tests in JS. I've just picked coffee, cause I find it easier to write.

Push your changes though, I'm interested in seeing how you managed to do this.

@rdwallis
Copy link
Contributor Author

Ok the codes all committed. I'm not actually sure that zFinalTests.coffee works but you can see the idea.

I think converting everything to plain javascript is probably the best solution.

@Pacane
Copy link
Contributor

Pacane commented Mar 14, 2014

I see what you did, but I don't see how it prevents the build from passing when there are compilation errors.

@rdwallis
Copy link
Contributor Author

Each variable checked by zFinalTests.coffee is set in one of the other coffee files. If one of the other coffee files doesn't compile then its variable will be undefined and zFinalTests.coffee will report the error making the build fail.


Anyway I think converting everything to plain js is a better solution.

@Pacane
Copy link
Contributor

Pacane commented Mar 14, 2014

Well if you want to rewrite, go ahead, but it works well with that fix. I like that 👍

@rdwallis
Copy link
Contributor Author

This is subsumed by PR #458

@rdwallis rdwallis closed this Mar 15, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants