Comments (5)
This "odd syntax" is what PHP itself uses for testing. And I have to say, it is way more readable and practical than PHPUnit and similar testing frameworks.
Your patch is very nice example why PHPUnit-like tests are bad. Your code looks like many other tests I saw, nothing bad at the first sight, but...
First, "109 additions and 40 deletions." ... the same feature, double the code. That is a bad sign.
Second, comparing the basic test I noticed few things.
- Tests are not numbered. Order of execution is important for tests. Once basic test fail, there is no need to look at more complicated tests. I guess PHPUnit has some dependency-related features, but numbering is better, because tests can act as a lectures built from examples.
- Expected values must be escaped to fit into strings and arrays. That is annoying, because it is harder to read. And this escaping must be done by a human. That is even more annoying. With PHPT you only have to copy-paste verified output, and sometimes replace changing parts with some wildcard.
- Asserts must be written. And human must think which asserts are required. A plain text diff done by PHPT checks all that with no effort. Really. Once your debug dumps produce nice result, you are done.
Take a look at PHPT -- http://qa.php.net/write-test.php and give it a few minutes of exploring.
Point is, that tests are not only to verify that code works. Actually that is one of minor reasons why tests exist. Good tests are awsome documentation -- working examples ready to run and experiment with. PHPT tests are also perfect as playground during development. You can write code, let it dump whatever is interesting, and once code works, little cleanup of debug dumps, copy-paste to expected section and feature is ready, including tests as an almost free side product.
And the most important, tests must be extremely easy to write. Otherwise nobody would write them.
from fluentpdo.
Hey, thanks for your feedback.
It really wasn't my idea to start a phpunit-phpt war, and I can truly understand that my patch could have been interpreted that way -- please excuse me if I was rude.
Regarding your comments:
I had included two features: (1) is phpunit support, and (2) is a small test case. To be fair you should say "32 additions, 31 deletions" for the same test. All the other additions are required to provide (a) no hardcoded configuration, (b) dynamic PDO driver tests.
Second,
- Running tests in the same order may lead to hidden bugs; that's why there are testrunner which shuffle them. This allows to ensure that each test is idempotent and thus not rely on the state left behind of other tests.
- The escaping thing is more a issue with the expected assert value than with the syntax itself (heredocs may help in such scenario, although I find them not nice)
- phpunit provides a good assert library which can handle more complex cases than plain text diff.. and it provides more insight about why it failed (like diff between arrays)
I'm not saying that phpt tests are bad; they are a good match for limited environments (such a php internals) but the defacto standard for php projects is phpunit.
from fluentpdo.
... please excuse me if I was rude.
No excuse needed. ;-)
To be fair you should say "32 additions, 31 deletions" for the same test.
Not really. The test you replaced has 10 lines of code. The rest, the "expected output", is written automatically and programmer only have to confirm that it is correct (by copy-pasting it into the file). That is the trick which makes such tests much easier to write.
Running tests in the same order may lead to hidden bugs ...
PHPT executes each test in new PHP instance (new process for each test). So if database is prepared and cleaned up correctly, there is no way they could interfere. Am I right? Does PHPUnit also execute each test in new process?
The escaping thing ...
phpunit provides a good assert library ...
With plain text diff there is no need for assert library in the first place. In some cases it may be better to use assert, but such case can be solved using better format of test output.
I'm not saying that phpt tests are bad; they are a good match for limited environments (such a php internals) but the defacto standard for php projects is phpunit.
150 lines of your commit says otherwise ;) It is ok to say that something is bad. I'm using PHPT in few other projects and I really want to know, whether there is a reason why I should not, or where are limits and shortcommings of such approach. Or if PHPUnit can provide some killer features which are worh writing more ugly tests.
from fluentpdo.
@eridal I appreciate your effort but sorry I agree with @jkufner. I don't see any advantages. On the other hand I see many drawbacks:
- phpt is less code
- phpt is more legible
Try to imagine someone who doesn't know phpt neither phpunit. What is easier to read for newbie? IMHO phpt.
On the other hand your reason for phpunit "defacto standard for php projects" is only
one of the typical rhetological fallacies : Appeal to popular belief - Claiming something is true, because the majority of people believe (use) it.
from fluentpdo.
I understand and respect your decision, however I think it's not in line with current modern development standards; test runner integration, coverage reports, profiling, dependency analysis are some benefits phpunit can bring (just on top of my mind) to the project.
Anyways, I'm not here to enlighten anybody.. so let's keep this closed as it's.
from fluentpdo.
Related Issues (20)
- Tables aliases broken ? HOT 3
- how i can use left join in foreach?
- PHP 8.0 support HOT 3
- Add params to SELECT method HOT 2
- Website not working HOT 1
- The select examples don't work HOT 1
- The ->fetchAll() can be used to put the result in a variable? HOT 1
- The fluent PDO passes parameters by "prepare" and "bindValue" to avoid sql injection? HOT 2
- Insert: lastval is not yet defined HOT 1
- Feature request: INSERT SELECT support
- PHP 8.1 Return type compatibility deprecation notices
- BETWEEN Method? HOT 2
- Undefined class constant 'PDO::FETCH_DEFAULT' HOT 1
- Excessive a.* clause HOT 3
- Use an object instead of an array for the update and insertInto function
- Error with %d format symbol inside select clause HOT 3
- Any news on 3.0? HOT 6
- Memory leak on multiple inserts/selects with big content HOT 1
- JSON data type support
- Cannot delete from tables with multiple primary keys HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fluentpdo.