ttiny / phptestr Goto Github PK

• Consider being able to embed the tests with the code like unitest-js . Even if this works this won't fully replace the current system, rather complement it, because this way would be very hard to trace errors etc, also code coverage and test scenarios that need more complicated logic (and possible databases, etc) can not be implemented this way.
• Consider being able to test nodejs also in the same UI, will be useful for the other pojects
• Consider being able to load the tests from several test suites at once and creating suites of suites
• Display files in stack traces and coverage relative to the target dir?

Consider the tester may run on a remote machine and in this case it shouldn't attempt to open a browser (with a switch), but it should serve the UI.

Also the backend and the frontend should be separate and talk over sockets so the backend could be on any machine. The backend should still be able to server the php log file to the frontend and it should still run the php scripts in sandboxes.

For example, lets say tests make bunch of requests and save bunch of logs. This is useful information needed for debugging, but should only be displayed in cases of error. So the tests should be able to save some stuff that is available via buttons, and optionally hide these buttons if there is no error. Or alternatively there should be some kind of special dumps that are hidden if there is no error, and in case of error a new button will appear that will reveal the dumps.

This wasn't implemented originally because one may want to keep the stuff in the browser window, but I find that everytime I close the server I want to close the browser tabs too. So it should keep some kind of persistent link with the browser and tell it to close the tabs. Consider there may be cases where the server crashes and closing the tabs is undesirable.

nodejs for sure, maybe browser too - communication with sockets. See also #8 .

Put all phptestr communication with the host on a dedicated socket and all output between the tests will be considered testEcho .

See also #17 .

• Use flexible layout so everything will fit perfectly, no need to care about IE9 in this particular app.
• Maybe add a header. See if something else can be made better.
• Add exit button.
• Make highlight.js replace tabs with two spaces, not four: hljs.tabReplace = ' '; // 4 spaces
• Put the docs in README.md.

Print proper error message for "Error: spawn ENOENT" when the php binary is missing. Actually there is no point of opening the browser if it is missing.

• Be able to specify the -phpbin option in the config
• Be able to specify the ini file for PHP from either command line or the config
• Have default configuration in json format in the app folder

• When starting without arguments do no autodetect phptestr.json in phptestr's directory - this is the global config
• Regarding 1.consider taking this from user's home first
• Be able to pass the full path of a phptestr.json in -target, this will allow for better OS integration (like "open with")
• Check if CLI tests return proper exit code on errors

Is it !$cond or $cond !== true.

This is probably due to nodejs bug that I was unable to catch.

This causes response.write/end() to do nothing after several response.write() calls.
http://ipgoeshere:3355/phptestr?target=../supplier-tester/master&args=gta/master

I tried custom queue without success. I also tried calling write() manually with lot of data many times and it worked.

function WriteQueueChunk ( towrite ) {
    this._towrite = towrite;
    this._next = null;
}

function WriteQueue ( response ) {
    this._response = response;
    this._next = null;
    this._last = null;
    this._end = null;
    this._drained = true;

    this._response.on( 'drain', this._onDrain.bind( this ) );
}

WriteQueue.define( {

    _onDrain: function () {
        this._drained = true;
        this._writeNext();
    },

    _writeNext: function () {
        if ( !this._drained ) {
            return false;
        }
        if ( this._next ) {
            this._drained = this._response.write.apply( this._response, this._next._towrite );
            this._next = this._next._next;
            if ( this._next === null ) {
                this._last = null;
            }
            return true;
        }
        else {
            return this._writeEnd();
        }
    },

    _writeEnd: function () {
        if ( this._end === null ) {
            return false;
        }
        this._response.end.apply( this._response, this._end._towrite );
        this._end = null;
        return true;
    },

    write: function () {
        var next = new WriteQueueChunk( arguments );
        if ( this._last ) {
            this._last._next = next;
            this._last = next;
        }
        else {
            this._next = next;
            this._last = next;
        }
        this._writeNext();
    },

    end: function () {
        this._end = new WriteQueueChunk( arguments );
        this._writeNext();
    }
} );

Node.js is good for streams, processes, etc. I had to build of all of this for PHP. Migrating this to node will take only few hours. Node.js can be started from a shell script and it can serve its own UI and open it automatically in a browser window. Apache is definitely not a dependency I want to have.

• Migrate phptestr.php, tests.php, lib/TestHost.php, lib/TestScriptRun.php to Node.js
• Move the rest to PHP 5.3 and remove the travelsdk-core dependency

Would be nice if the frontend is not so dirty and implemented as a neat app using the same frontend as jsdocgen .

Also:

• Have button for pretty stack trace - only files and lines in the gui
• Show code coverage
• Remove the raw button if no debug argument is passed
• Have Node start a web server and serve the UI, this way we can keep list of recently tested targets or select a target without typing

Sometimes Chrome sends a request to Node.js, but node never receives it and Chrome keeps spinning for very long time. While it is doing so the UI won't work (even in a new tab) and you need to restart Chrome. I can't reproduce it nor I have any idea what could cause this.

When launching the php binary enable via command line args "short tags" and also see if it makes sense to force and is it possible to prevent changes to other important ini settings. If it is possible to prevent these change add the same feature to jsdocgen.

When viewing exceptions and coverage.

• Display files in stack traces and coverage relative to the target dir?
• In the coverage panel highlight the file that is currently being shown in the source view
• In the test results view it is easy to loose your script from sight when collapsing/expanding - animate highlight in the title as in 0.8
• File names in coverage shouldn't wrap and they should be h-scrollable on overflow
• In code coverage do not highlight lines which have only a } on them.
• Functions calls without arguments are displayed as {} in stack traces, makes no sense
• Add "Open" buttons for all scripts in the main view, not only for stack traces.
• When walking the stack trace scroll the highlighted line to the center of the window, not to the top

Won't be 100% accurate because xdebug's reports are primitive. Should ignore whitespace lines, bracket lines, function and class definition lines, class property definition lines, class const definition lines. The rest should be somehow usable.

Tests should be able to run without the UI, so testing can be automated in scripts... with some colors and possible logging of all the info that the UI provides.