10

Mam serię testów Jasmine uruchomionych przeciwko usłudze AngularJs korzystającej z interfejsu ECMAScript Internationalization API. Wszystkie działają pomyślnie, gdy uruchamiam je w Chrome. Jednak, gdy używam PhantomJS, aby uruchomić je przez maven, wszystkie zawodzą, ponieważ wydaje się, że PhantomJs nie obsługuje jeszcze interfejsu Internationalization API.Interfejs API internacjonalizacji Javascript nie jest obsługiwany przez PhantomJS

Komunikat o błędzie uzyskać do testów wykorzystujących Intl przedmiotu jest:

1: ReferenceError: Can't find variable: Intl in localizationService.js

A reszta testów prostu zawodzą.

Testy są proste i wyglądać tak:

it('Format date with en-us locale', (function(){ 
    var date= "06/13/2013" 
    expect(service.date(date,'en-us')).toEqual("6/13/2013"); 
})) 

i metody eksploatacji (localizationService.js) są proste obwolut wokół Intl API:

function getCurrentTimeZone(){ 
    return Intl.DateTimeFormat().resolved.timeZone 
} 

function date(dateInput,locale,options){ 
     // some other stuff 
     // ... 
     if (locale) { 
      return _date.toLocaleDateString(locale,options); 
     } else { 
      return _date.toLocaleDateString(); 
     } 
} 

Moje pytania to:

1- Czy moje założenie jest prawidłowe, ponieważ PhantomJS v1.9.2 nie obsługuje ECMAScript internationalization API? Czy mimo to to potwierdza?

2- Jak mogę podejść do rozwiązania tego problemu? Muszę przeprowadzić testy za pomocą programu maven i będę mieć więcej testów trafiających w mój interfejs API servicealization w taki czy inny sposób.
Dzięki

Odpowiedz

23

Nie wiem, czy używasz Karmy, czy nie, ale oto, co musiałem zrobić, aby rozwiązać ten sam problem.

  1. npm install karma-intl-shim --save-dev

    Będzie to również zainstalować bibliotekę PolyFill Intl;

  2. Dodaj "intl-shim" do kolekcji frameworków w pliku karma.conf.JS:

    ... 
    frameworks: ['intl-shim'], 
    
  3. dodać plik lokalizacji chcesz przetestować zw karma.conf.js, na przykład 'en-US':

    ... 
    files: [ 
         './node_modules/Intl/locale-data/jsonp/en-US.js', 
    ... 
    
+0

ta odpowiedź jest o wiele lepsza. Proponuję zaakceptować to jako poprawną odpowiedź. Twoje zdrowie! – activedecay

+1

Pracowałem też dla mnie. Oprócz powyższych kroków, trzeba było dodać tę linię: require ("karma-intl-shim") do tablicy wtyczek w pliku karma.conf.js – vanval

+0

Jeśli używasz testów z --single-run = false, musisz wyjść z tego i ponownie uruchomić proces, zanim zaczną obowiązywać zmiany w pliku 'karma.conf.js'. Straciłem około godziny na tym ... –

6

1- Is my assumption correct that PhantomJS v1.9.2 does not support ECMAScript internationalization API? Is there anyway to confirm that?

to wygląda PhantomJS jest oparta na silniku WebKit, tak że nie obsługuje nową ECMAScript internacjonalizacji API.

Nawet dla Chrome, API robione to do V8 dopiero niedawno, nadal jest w beeding_edge, a nie w głównym: Zobacz http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/ pliki i18n (.cc, .h, JavaScript powinny). Oznacza to po podzieleniu z WebKit.

Oto obecny stan wsparcia i18n: http://mihai-nita.net/2013/07/28/javascript-internationalization-api/

2- How can I approach resolving this issue? I need to run my tests through maven and I will have more tests hitting my localizationService API one way or the other.

Jeśli byłbym opiekun PhantomJS chciałbym rozważyć wyjście z oddziału Google z WebKit, zanim oni odbiegają zbytnio i uczynić go zbyt trudne do nadrobienia. Chrome ma więcej rynku niż Safari (nie i zaproszenie do wojen płomieniowych, tylko osobiste zdanie bez ciężaru :-)

Nie znam PhantomJS, i nie wiem, co oferuje, ale jeśli możesz oddzielić testy JavaScript, aby uruchomić na v8, możesz spróbować użyć go do testowania z linii poleceń. Budowa beeding_edge była bezbolesna i zrobiłem to na Win, Mac OS X i Linuxie bez żadnych problemów.

+0

Mihai, dziękuję bardzo za Twoja odpowiedź. Spróbuję podejścia V8. – Alidad

+0

Jeśli chciałbym przetestować inną bibliotekę podczas dojrzewania api, co poleciłbyś? Grałem z chwilą, timezonejs, i jest tak wiele innych, ale co byłoby niezawodne w projekcie wrażliwym na strefy czasowe? – Alidad

+0

Większość szkieletów JavaScript w dzisiejszych czasach ma coś dla i18n, w tym jQuery, Dojo, Closure. Nie znam ich zbyt dobrze, wolałbym postawić na standard lub shim dla standardu. Zamknięcie ma coś dla strefy czasowej, ale tak naprawdę jej nie używałem (http://docs.closure-library.googlecode.com/git/class_goog_i18n_TimeZone.html, http://docs.closure-library.googlecode.com/git/ namespace_goog_locale_timeZoneDetection.html oraz formatowanie daty/czasu uwzględniające strefę czasową). –