Gdy sam udało mi się wymyślić rozwiązanie, pomyślałem, że warto go udostępnić. Podejście może nie być bezbłędne, ale wydaje się, że to pierwsze działa. Możesz publikować poprawki i sugestie.
Co zrobiłem w pigułce:
- Wprowadzenie instancją Xvfb, wirtualny bufora ramki
- Korzystanie JsTestDriver:
- uruchomić instancji Firefoksa do wirtualnego bufora ramki (headlessly)
- przechwytywanie instancji Firefox i uruchomienie zestawu testów
- generować wyniki testów JUnit zgodny .xml
- Zastosowanie Bamboo wglądu do wyników plik do pozytywnej lub negatywnej Build
będę obok przechodzą bardziej szczegółowych etapów.To właśnie moja moja struktura katalogów skończyło się patrząc jak:
lib/
JsTestDriver.jar
test/
qunit/
equiv.js
QUnitAdapter.js
jsTestDriver.conf
run_js_tests.sh
tests.js
test-reports/
build.xml
Na serwerze produkcji:
- Install Xvfb (
apt-get install Xvfb)
- zainstalować Firefoksa (
apt-get install firefox)
Do wniosku, który zostanie zbudowany:
server: http://localhost:4224
load:
# Load QUnit adapters (may be omitted if QUnit is not used)
- qunit/equiv.js
- qunit/QUnitAdapter.js
# Tests themselves (you'll want to add more files)
- tests.js
utworzyć skrypt f Ile do uruchamiania testów jednostkowych i generowanie wyników badań (przykład w bash, run_js_tests.sh):
#!/bin/bash
# directory to write output XML (if this doesn't exist, the results will not be generated!)
OUTPUT_DIR="../test-reports"
mkdir $OUTPUT_DIR
XVFB=`which Xvfb`
if [ "$?" -eq 1 ];
then
echo "Xvfb not found."
exit 1
fi
FIREFOX=`which firefox`
if [ "$?" -eq 1 ];
then
echo "Firefox not found."
exit 1
fi
$XVFB :99 -ac & # launch virtual framebuffer into the background
PID_XVFB="$!" # take the process ID
export DISPLAY=:99 # set display to use that of the xvfb
# run the tests
java -jar ../lib/JsTestDriver.jar --config jsTestDriver.conf --port 4224 --browser $FIREFOX --tests all --testOutput $OUTPUT_DIR
kill $PID_XVFB # shut down xvfb (firefox will shut down cleanly by JsTestDriver)
echo "Done."
Załóż Ant cel, który wywołuje skrypt:
<target name="test">
<exec executable="cmd" osfamily="windows">
<!-- This might contain something different in a Windows environment -->
</exec>
<exec executable="/bin/bash" dir="test" osfamily="unix">
<arg value="run_js_tests.sh" />
</exec>
</target>
Wreszcie powiedzieć Bamboo zbudować plan zarówno wywołaj cel test i odszukaj wyniki testu JUnit. Tutaj domyślny "**/test-reports/*.xml" będzie dobrze.
Czy wydaje Joshua Flanagan ma pochodzić z czymś podobnym w środowisku C#/IE, używając Watin, NUnit i IterativeTest: http://www.lostechies.com/blogs/joshuaflanagan/ archiwum/2008/09/18/running-jquery-qunit-tests-under-continuous-integration.aspx? CommentPosted = true # commentmessage – miek
RhinoUnit zapewnia możliwość uruchamiania testów jednostkowych JS bez głowy, jednak dodanie obsługi QUnit prawdopodobnie wymagałoby trochę dodatkowej pracy: http://code.google.com/p/rhinounit/ – miek