Celerity, javascript setRequestHeader

I znów problem z testowaniem.
Mam sobie indeks sprzedawców. W tabeli. Każdy z nich ma obok linka “Szczegóły”, który wykonuje połączenie ajaksowe do serwera. Serwer odsyła JSa, który powoduje wyświetlenie okna dialogowego (tego z jQuery, opartego na DIVie). W przeglądarce wszystko działa:

Gdy kliknę w link Szczegóły wykonywane jest żądanie do serwera:

[code]SQL (0.2ms) SET client_min_messages TO ‘panic’
SQL (0.1ms) SET client_min_messages TO ‘notice’

Processing SellersController#show (for 127.0.0.1 at 2009-09-19 18:12:39) [GET]
Parameters: {“id”=>“551”, “_”=>“1253376759365”}
Seller Load (1.0ms) SELECT * FROM “sellers” WHERE (“sellers”.“id” = 551)
Rendering sellers/show
Rendered sellers/show (3.1ms)
Completed in 29ms (View: 5, DB: 1) | 200 OK [http://localhost/sellers/551?
=1253376759365][/code]
Natomias z poziomu culerity dzieje się coś dziwnego. “Kliknięcie” w link powoduje zapytanie:

[code]SQL (0.1ms) SET client_min_messages TO ‘panic’
SQL (0.1ms) SET client_min_messages TO ‘notice’

Processing SellersController#show (for 127.0.0.1 at 2009-09-19 18:14:05) [GET]
Parameters: {“id”=>“552”, “_”=>“1253376845712”}
Seller Load (0.6ms) SELECT * FROM “sellers” WHERE (“sellers”.“id” = 552)
Rendering template within layouts/application
Rendering sellers/show
Rendered sellers/_show (2.2ms)
Rendered shared/_menu (0.2ms)
Rendered shared/_context_menu (0.2ms)
Rendered shared/flashes (0.5ms)
Completed in 22ms (View: 8, DB: 1) | 200 OK [http://localhost/sellers/552?
=1253376845712][/code]
Patrząc po zapytaniu wygląda tak jakby w przeglądarce był wyłączony JavaScript.
Gdy w kontrolerze zakomentuję linijkę:

[code] def show
@seller = Seller.find(params[:id])

respond_to do |wants|
  #wants.html 
  wants.js
end

end[/code]
i usatwię jedyną metodą zwracanai danych javascript,
to wtedy testy przechodzą.

Wydaje mi się że culerity ignoruje setRequestHeader w jQuery (które ustawiam w application.js) i wysyła swój.
Wie ktoś coś o tym? Wolałbym nie eksperymentować jednak z selenium :smiley:

Spróbuj odwrócić kolejność wants.html i wants.js (pierwsze js). Miałem taką sytuację, że pod IE kolejność miała znaczenie.

Hm no tak, ale to przeglądarka powinna decydować jakiej zawartości oczekuje. Jeśli np. IE nie wysyła takiej informacji to w przypadku, gdy JS jest wyłączony do przeglądarki zostanie wysłany plain-JavaScript.

Edit
Testy przeszły, choć nie sądzę, żeby to było w porządku. Zaraz przetestuję na IE z wyłączonym JS.

Edit2
IE 6 faktycznie przy wyłączonym javascripcie próbuje pobrać JSa I wyswietla informację, że przy obecnym poziome zabezpieczeń nie można wykonać skryptu. Zastanawia jednak, dlaczego, gdy w Culerity mam ustawione jako browser firefox3 (firefox ma to samo) zachowuje się jak IE?

Podglądnij nagłówki żądania jakie wysyła przeglądarka podczas testów a jakie podczas normalnego użytkowania. Podejrzewam, że leci inna wartość w polu Accept.

Potwierdzam to z kolejnością wants. Też u mnie się dziwne rzeczy działy z takim ustawieniem.

[quote=sevos]Edit2
IE 6 faktycznie przy wyłączonym javascripcie próbuje pobrać JSa I wyswietla informację, że przy obecnym poziome zabezpieczeń nie można wykonać skryptu. Zastanawia jednak, dlaczego, gdy w Culerity mam ustawione jako browser firefox3 (firefox ma to samo) zachowuje się jak IE?[/quote]
Celerity korzysta z HtmlUnit, który tylko emuluje firefoxa/ie. Ciężko stwierdzić jak to dokładnie działa.

W niektórych sytuacjach celerity nie da rady (na przykład google maps testy w celerity nie przechodzą, testy w firewatirze ok) i tak czy siak trzeba będzie uruchomić przeglądarkę - na szczęście pod to samo api można podpiąć np. FireWatira. Część scenariuszy możesz na przykład otagować @realbrowser czy coś w ten biznes - żeby nie trzeba było wykonywać wszystkiego - w porównaniu do przeglądarki w pamięci jest to naprawdę dużo wolniejsze.

Tak, tylko tu chodzi o tak podstawową rzecz jak przetwarzanie *.js.erb, a konkretnie wysyłanmie odpowiedniego zapytania AJAXowego (z xhr headerem “Accept: text/javascript”). W tym momencie wygląda na to, że wszystko powinienem odpalać pod Selenium czy Firewatirem. Testy ni-javascriptowe moge sobie pod zwykłym webratem wykonywać.

Edit:
wygląda na bug w HtmlUnit
http://www.nabble.com/Htmlunit-v2.5-seems-to-have-broken-ability-to-set-specific-ACCEPT-header-for-a-request-td23455262.html

Problem w tym, że z tego co wyczytałem to oni to poprawili, mam w celerity wersję 2.6 HtmlUnita i sprawdziłem debuggerem, że pomimo ustawiania w javascript nagłówka, HtmlUnit wysyła HTTP_ACCEPT="/"

A wydawałoby się takie proste…

Nie chodziło mi tutaj o to, żeby w tym wypadku użyć selenium/watira - to jest rzeczywiście podstawowa funkcjonalność i powinna raczej działać. Chodziło mi o jakieś cięższe przypadki - to było takie wtrącenie w kontekście dziwnych zachowań “wirtualnych” przeglądarek.

[quote]Edit:
wygląda na bug w HtmlUnit
http://www.nabble.com/Htmlunit-v2.5-seems-to-have-broken-ability-to-set-specific-ACCEPT-header-for-a-request-td23455262.html

Problem w tym, że z tego co wyczytałem to oni to poprawili, mam w celerity wersję 2.6 HtmlUnita i sprawdziłem debuggerem, że pomimo ustawiania w javascript nagłówka, HtmlUnit wysyła HTTP_ACCEPT="/"[/quote]
Obadam sprawę, bo jak na razie na coś takiego nie natrafiłem. W aplikacji, w której używam celerity większość odpowiedzi zwraca JSON, który jest obrabiany już w javascripcie.

Przygotuj się na jeszcze więcej takich problemów :wink: Naprawdę, to nie jest jeszcze porządnie przetarty szlak. Więcej szczęścia możesz mieć z selenium chociażby, bo jednak to jest standard w funkcjonalnych testach.

Wyobrażasz sobie Test Driven Development z udziałem selenium? :wink:
Ciekaw jestem co wydumasz z tym HtmlUnitem, ja jeszcze pogooglam, ich mailing-listy nie są łatwo przeszukiwalne.

Edit:
Próbowałem podmienić jara htmlunita w zainstalowanym gemie celerity na wersję z svnu (last build), ale bez zmian. W dodatku spróbowałem usunąć tego jara, a testy i tak się odpalały. Jakby htmlunit w ogóle nie był brany pod uwagę. Albo gdzies wisi w pamięci.

Edit2: obiecujący post:
http://lists.canoo.com/pipermail/webtest/2009q2/012408.html

Na pewno działa trochę wolniej niż celerity, ale chyba się da? :slight_smile:

Tomash ponoć działa z selenium, może on coś na ten temat powie.

U mnie działa najnowsze culerity + celerity 0.0.6 (czyli htmlunit 2.5)

Na celerity 0.0.7 jest tak jak piszesz :]

Dziwne :slight_smile:

Spójrz sobie na linię 63 :wink:

http://htmlunit.svn.sourceforge.net/viewvc/htmlunit/trunk/htmlunit/src/main/java/com/gargoylesoftware/htmlunit/WebRequestSettings.java?view=markup

Spróbuję celerity 0.0.6 zainstalować, zobaczymy :>

Edit:
Na 0.0.6 DZIAŁA :smiley: Dzięki.

Nie sądzę, żeby to była przyczyna. To jest wartość domyślna i rzeczywiście bez żadnych zmian zwykłe browser.goto() wysyła taki Accept. To raczej jakiś błąd w silniku do js, który nie pozwala zmienić nagłówków w javascripcie.

Przy celerity 0.0.6 wygląda to tak:

[code]# zwykły GET
“HTTP_ACCEPT” => "/

ajax - ustawione przez jQuery

“HTTP_ACCEPT” => “text/javascript, application/javascript, /”[/code]
Przy 0.0.7:

[code]# zwykły GET
“HTTP_ACCEPT” => "/

ajax

“HTTP_ACCEPT” => “/”[/code]
Nic nawet nie pomoże ręczna zmiana headerów w jQuery:

$(document).ajaxSend(function(event, request, settings) { request.setRequestHeader("Accept", "text/javascript, application/javascript, */*"); });

[quote]Edit:
Na 0.0.6 DZIAŁA :smiley: Dzięki.[/quote]
Teraz tylko trzeba zgłosić buga do HtmlUnit, żeby można było używać najnowszego celerity ;]

Przy okazji - przeglądałem repo culerity i została częściowo zaimplementowana obsługa bloków, z tym że każdą metodę z blokiem trzeba implementować oddzielnie w culerity. Na razie jest tam metoda confirm, resztę trzeba dodać, albo poczekać aż ktoś to zrobi :wink:

Update:

Dlaczego ludzie muszą sobie tak komplikować życie? Żeby dodać ticket na bug trackerze do htmlunit trzeba się zarejestrować na sourceforge i wysłać maila do któregoś z adminów projektu. I wtedy może łaskawie mi umożliwią dodanie ticketa. Jakby to był projekt, którego mniej używam, albo miałbym zamiennik, to olałbym i nie tracił nawet czasu…

Update2:

Ok, mój błąd, kliknąłem w nie tego linka co trzeba i wyskoczył jakiś permiszyn dinajd.

W razie czego tutaj jest ticket: http://sourceforge.net/tracker/?func=detail&atid=448266&aid=2862553&group_id=47038

Błąd naprawiony w HtmlUnit, teraz tylko czekac na nowy gem Celerity…

Albo sobie sforkować :wink:

Na pewno działa trochę wolniej niż celerity, ale chyba się da? :)[/quote]
Nie jest aż tak tragicznie. Selenium działa całkiem sprawnie, jednak zawieszająca się przeglądarka czy wyskakujące okienka mogą skutecznie odciągnąć delikwenta od samego sedna tej czynności – czyli testowania :).

Trzeba poczekać aż celerity/watir/selenium wejdą do mainstreamu wśród railsowców - po osiągnięciu odpowiednio dużego community problemy znikają bardzo szybko :slight_smile:

Nie wejdą, nie póki warunkiem będzie instalowanie borga (jvm) i odpalanie aplikacji w JRuby. Prędzej webrat dorobi się jakiegoś silnika JS :]

Nie trzeba odpalać aplikacji w JRuby.

Po to jest culerity. Wszystko co musisz zrobić to odpalić mongrela. Kroki wykonują się normalnie w takiej wersji rubiego jakiej używasz, po prostu pod spodem instrukcje dla celerity są wysyłane do specjalnego procesu z celerity.

Na przykład robisz browser.goto(“http://google.com”) i culerity przesyła to do procesu celerity (odpalonego na jruby) używając pipe’ów, a celerity zwraca odpowiedź.

Z punktu widzenia usera jedynym dodatkowym krokiem jaki trzeba wykonać jest zainstalowanie jruby.

O, to nie wiedziałem. Zatem obadam :slight_smile:

@Tomash::

./rdt meta:testing_studio:install

z rordevtoolkita instaluje wszystko co trzeba :wink: