Rename SimpleTest to Testing (test.module)

This probably requires a bit of discussion since webchick has pointed out several times that it would be good to keep the framework similar to SimpleTest so that people can transfer there skills from SimpleTest -> Drupal Testing and back. Having it named accordingly would be helpful to that end.

Another concern is that testing is a verb and the module names are nouns.

Can we get a consensus on this so we can close this issue?

My vote: opposed

I still think the point webchick brought up and I wrote in comment #2 stands.

It's my opinion that any and all moves we make that make our testing framework less like SimpleTest are moves in the wrong direction. SimpleTest is widely used, with copious numbers of tutorials, API docs, and so on that we as a community don't have to re-write. People coming from other projects where they've used SimpleTest should be able to jump write into writing tests for Drupal with as little learning curve as possible. Similarly, those who have written tests for Drupal should be able to transfer that knowledge to using SimpleTest on other projects.

So I oppose this change because I oppose the basic idea of stripping out all the SimpleTest-ness of SimpleTest and replacing it with some custom testing framework that people have to re-learn. I would much rather make our testing framework be *more* like SimpleTest, not less. And if we don't like something about the way SimpleTest is? It's open source. Let's work with them to improve it.

And my response to *that* is that I'd need a very good and strong reason why we shouldn't revert the "hacks" we made to stock SimpleTest library, if they won't accept them. They're more familiar with their library than we are, with far more developers using their product than just us. What is their justification, and can we build that different logic into drupal_web_test_case.php instead?

And my response to *that* (this is fun! :D) is that I care far less about lightweight code than I do about low barrier to entry for developers and the Drupal project NOT having to divert our own resources towards maintaining our own custom testing framework that we're also responsible for bug-fixing, since we're the only ones who use it, and pulling in patches from upstream that fix security issues or add additional API features that people are going to expect us to have, and... I'd love to see the folks from the testing sprint spend their considerable talents helping improve Drupal's *test coverage*, and doing education around that, than wasting effort solving problems that SimpleTest already solved, just in a more "Drupal" way, thus locking us into yet more code to maintain without help from the entire SimpleTest development community.

It's the same reason we use jquery.js (5.x+) and not drupal.js (4.7.x) as our JS framework. Let people dedicated to it worry about how to make a good framework, let us just use it.

Shall we mark this one closed? Or is it still open for debate?

I think it is still open for debate.

How about this? We rename it testing after http://drupal.org/project/issues?projects=3060&components=tests&states=1... shows no core test failures. :P~~~

;)

The module names as they are written are independent of actual directory name. Lots of modules differ in the way they are written in text vs. directory name.

I'm still not convinced. :)

Lets just make sure the result is diffed against repository. Otherwise Dries can just apply the first portion of the patch and rename the directory himself to ensure the files are the same.

Just 'testing' seems like the best choice to me. It's the most Drupal-ish. I'm ready to commit this patch and add/remove the necessary files when it is marked RTBC.

I started making notes on comments in this patch before I realized how long it was. I stopped because it would be easier for me to capitalize comments and add periods than write about the need to do so. I'm temporarily assigning to myself and will go through this with a text editor in a bit.

Well. poxy on that. Actually this no longer applies very cleanly (mostly but not exactly) and I'm not nearly up enough on testing to know exactly how to fix it. If someone can sync it up with today's head and repost, I'll clean up the code comments, though.

@keith - this patch does not add or change any code comments, so that should go in a separate issue.

Ah. After a second look I see what it's doing now. There are some comments that need fixing, but they can indeed go in a different issue after this one is resolved. Sorry for the sidetrack.

Works great. Only thing that stuck out was "Testing is initializing" - changed this to "Test framework is initializing". Marking RTBC, please don't credit on commit.

Doesn't apply smoothly. Doesn't look up-to-date.

The main work will be renaming/moving files areound directly in the repository - maybe we can get sign-off form Dries and then a window of a few days where no patches should touch these files except the one needed to rename the module functions?

Yea, once t.d.o is up and running. Fair amount of issues with server #321659: testing.drupal.org down, Centos repair needed I will focus on getting a few other SimpleTest patches cleaned up and committed.

Then I would feel more comfortable with this.

Waiting for D7 freeze.

Dries, I'm operating under the assumption that small "clean-up" changes like this (as well as moving tests around en-masse so they are more consistent) are things that can happen at the very start of code freeze so we do not needlessly break every patch in the queue during our most critical development time. If this is an incorrect assumption, please let us know because then we really should do this sooner than later.

Back into business.

Can we simply commit this for starters?

I'm not sure whether it's really worth renaming the entire module folder, classes, files, etc. At least, I can handle that. But what confuses me each time I want to enable the "Testing" module to get my testing environment is that I need to enable "SimpleTest", not "Testing"....

I think that making the name change in only that single place will make for a lot of confusion. I think it's bad practice to have a module in the simpletest directory with a simpletest.info file name itself "testing" instead of "simpletest". Also, the documentation still also consistently refers to SimpleTests. Doing the change this way sounds too much like the taxonomy/categories tale, with the admin link labeled "categories" going to admin/content/taxonomy and info text reading "The taxonomy module allows you to...".

If I were the SimpleTest project, I'd be unhappy with this 'fork' because it creates confusion between the two projects.

If they have a SimpleTest trademark (don't know if they do), they will probably demand that we rename our fork -- and rightly so. We can still say 'Based on SimpleTest' but the two projects and code bases are different enough that they really should have a different name.

In other words, we must rename this. For starters, I committed the patch in #33 but it would be good to re-roll the earlier patch too.

And if we add js testing...it is even less SimpleTest, #237566: Automated JavaScript unit testing framework. I am happy to role a full patch...I just need to know that the time is right and it will be committed...as otherwise it will need constant re-rolling.

Yes, this would break every single mission critical patch in the queue now. Let's defer this to right after API freeze.

This will break every patch with test even after the API freeze, so the reason for postponed status is unclear.. And we are in "some kind of" API freeze already..

This should only break patches to simpletest...rest of core should be fine, right?

Yeah. And I do think this is worth doing. It's inaccurate at best to name our totally custom testing framework after another project it has absolutely nothing to do with, other than loosely sharing a syntax. Also, I don't know that there is a SimpleTest Foundation who has a trademark on the name and goes after people who name their custom testing frameworks SimpleTest, but since D7 will be around for another 3-4 years at least, it's probably not worth testing the theory. ;)

This requires coordination tho since testing bot will of course break.

When is a good window to reroll this patch?

Too late for D7 now.

I'm not sure, but this might conflict with #1076130: Fully pluggable testing.

Updated issue summary.

If possible, I'd like to do this before #1541676: Convert Simpletest base test classes to PSR-0

I've rewritten and clarified the issue summary.

Sorry, typo.

I am fine with test module.

PIFR currently has 'simpletest' hard-coded, so I've created #1556696: Prepare for simpletest.module rename to test.module (D8) to adjust it for the rename.

Simpletest is broken beyond repair. I can prove and explain that with a long list of architectural design problems.

We will go an entirely different route. Renaming is pointless and will only waste time.

I'll try to do a write up as soon as time permits (and after calming down to not make it a total rant). That said, it's going to be huge undertaking that potentially needs funding and possibly also a digital or in-person sprint.

Been saying the funding and rewrite/new framework for a while...something tells me you will have more sway.

Updated issue summary.