Status & Todo about simpletest HOT 5 CLOSED

Great to see to activity back up !

Since lastcraft.com is down, we could put everything on "simpletest.org" (I should still have the credentials for that serveur ;-). And aim for a release down the year...

Yours, Perrick

from simpletest.

Hi!

Just stashing the pages in simpletest.org would be good. Those "crazy" tests actually caught a lot of errors in the past, so I wouldn't ditch them entirely :).

If you want I could resurrect the lastcraft.com site. Haven't had a need to 'til now, but I suspect that you are missing some Google love as a result. If there is anything you need, let me know.

yours, Marcus

from simpletest.

Hey!

Good to see you both back.

I apologize for being so pushy and introducing BC breaking changes without any prior communication and asking.

By calling the acceptance tests "crazy" i was referring to the way they are executed.
I consider network based tests, which access external servers a bad practice, because they tend to fail for external reasons. So i would like to suggest to take "live testing over the network" out of the equation for executing these tests and prefer a "loopback" approach, where the related pages are served via PHPs internal webserver on Travis and the tests are executed against it.
I'm suggesting this, because (a) testing on localhost is faster and (b) it doesn't cause additional outbound network traffic and (c) the number of requests to the server can quickly add up making a server unresponsive, because each push to the repo triggers multiple builds (PHP version matrix) each executing the acceptance test. The required steps for getting this done are minimal.
Some additions to the Travis configuration to get the PHP server up and the reactivation of the tests.

Over time several users requested a Composer integration and so the composer.json was added,
despite the fact that the repo is not Composer friendly at all. The problem is, that with each Composer installation the complete repository is fetched, including files and folders unnecessary for working with SimpleTest (e.g. the build tools for docu and release, the website, private folders for translations).
I would like to suggest reducing the files/folders to only the necessary ones.
One way would be moving things into individual branches of the repository.
Another way would be to split the subtrees into new repositories.
Is altering the repository layout for Composer ok?

Regarding the website, there is also the option to serve the page via Github Pages.
This could be done by pushing the website to a "gh-pages" branch with a configuration file accepting the CNAME for a domain, allowing simple updates to the website via git.

So, next to these build infrastructure decisions, it would be nice to update the todo list (http://simpletest.org/en/todo.html), leave the "maintenance mode" and do a new release supporting the newer PHP versions.

What are your plans for the project?

Looking forward discussing the next steps for the SimpleTest project with you.

from simpletest.

Hi there!
I used Simpletest WebTester(!) quite a lot in older CakePHP projects, but paused some years lately. Meanwhile I started to work with TYPO3 and tried to rebuild my old TDD experience with PHPUnit and Selenium(HtmlUnit/PhantomJS). Maybe I am not smart enough, but I could not get it running fast enough to be suitable for TDD. And I am definetely not smart enough to easily dig into heavy Java/Javascript code to get insights of the tools I am using. So I am back with Simpletest Webtester. Easy, simple, fast - and good. I love this tool. I am happy like a kid to use it again.
Todo:

• get the code namespaced? May help others to jump into Simpletest more easily. May help one clicking through the code.

from simpletest.

Hey Henri! Welcome back to SimpleTest :)

I like your idea of introducing namespaces, but its a heavy refactoring and will cause a big BC break.
It changes every file, introduces new ones, changes the API and makes follow-up changes to the docs necessary. I think it implies giving up the multiple-classes-per-file concept with direct file includes, in favor of autoloading namespaced classes with one-class-per-file.

Yes, it might help other devs to understand the code a bit faster, just by looking at the exposed file and folder structure. And we can also do some more cleanups on the code-base while doing it, but..
its definitely a huge undertaking. We would need to stabilize SimpleTest first with a solid code-coverage percentage and report, before we should/could start working on this.
Lets tag this as "nice to have", "in the future" and "v2.0.0".

from simpletest.