peridot-php / peridot Goto Github PK
View Code? Open in Web Editor NEWEvent driven BDD test framework for PHP
Home Page: http://peridot-php.github.io/
License: MIT License
Event driven BDD test framework for PHP
Home Page: http://peridot-php.github.io/
License: MIT License
Application as an argument is not useful in the peridot.configure event. It fires too late for most purposes. Application work should be handled in the peridot.start event always.
need to invoke teardown to proceed with remaining tests
We should be cool and make functionless tests default to pending if a function is omitted.
describe("My rad thing", function() {
it("should do a rad thing"); //pending
it("should do another rad thing"); //pending
});
We should suppress non fatal errors and make them available to reporters.
We should support some variety of pending specs - probably via x
style functions:
<?php
xdescribe('A pending suite', function() {
xit("pending spec", function() {
});
xcontext("pending context", function() {
});
});
We should probably start documenting things with phpdoc comments, as well as add them to existing code.
Make it happen.
currently the application loads suites twice on successive runs. It should only load once.
We need a way to report failures and maybe successes? As an option? We should keep in mind that reporting should be a HIGHLY configurable part of peridot.
I had a crack at integrating a mocking library I'm working on with Peridot, and ran into this small issue. Here's the output:
Phony
โ should record passing mock assertions
1) should record failing mock assertions
1 passing (28 ms)
1 failing
1) Phony should record failing mock assertions:
Expected call on PhonyMock_TestClassA_0[1]->testClassAMethodA with arguments like:
<'a'>, <'b'>
Never called.
(stack trace)
So, basically I would expect this section:
Expected call on PhonyMock_TestClassA_0[1]->testClassAMethodA with arguments like:
<'a'>, <'b'>
Never called.
to be rendered like:
Expected call on PhonyMock_TestClassA_0[1]->testClassAMethodA with arguments like:
<'a'>, <'b'>
Never called.
This should be correct behavior for tests:
beforeEach(function() {
$this->thing = "thing";
});
beforeEach(function() {
$this->dependsOnThing = $this->thing . " is depended on";
});
Currently they run in reverse order.
Since we use the static PHP_Timer
methods in the reporter, there is a chance of overwriting the data by calling PHP_Timer
methods elsewhere.
It would probably make more sense to just store microtimes and use the PHP_Timer
formatting function (or write our own).
Exceptions are much are more useful for us. For now set in bootstrap and possibly make it default behavior with option to turn off?
<?php
assert_options(ASSERT_CALLBACK, function($script, $line, $message) {
throw new \Exception($message);
});
For consistency with rename of classes and files, spec.* events should be test.*
Currently - a pending suite, or a suite that does nothing is created by passing a noop function to the suite:
$suite = new Suite('does nothing', function () { });
It would be nice to have this work as it does in tests.
$suite = new Suite('does nothing');
We should integrate these into the project:
We need a wiki demonstrating some testing with Peridot - good practices, leveraging some of BDD's strengths.
We should also make a point of stressing some of the features that distinguish Peridot - primarily events, plugins, reporters, and especially scopes.
In preparation for #120 - we should at least create a getter and setter for the runner object used in Console\Command
.
We need a command line executable for peridot. For now should only take a single argument that is a path to a specific spec file or a directory of specs. Eventually the runner should accept some configuration via a file (yml? json?) or as command line switches for things like loading conventions, reporter to user, etc...
peridot specs/
peridot specs/runner.spec.php
Is there any reason to use the PHP_Timer
class? Are there any issues with just using PHP's DateTime
class and formatting it? Never a bad thing to eliminate a dependency.
Related to #117 - it would probably be a good thing to have a generic error interface that can be used.
I imagine it would mirror what is already available to PHP exceptions, but create an interface for objects that are not actually exceptions.
A build process would be rad. Something that updates Console\Version, docs, and the phar and gets them where they need to go.
This is broken again:
describe('A sandwich', function() {
$this->sandwich = ['delicious' => true];
it('should be delicious', function() {
assert($this->sandwich['delicious'], "should be delicious"); //Exception: Scope property not found
});
});
A test should be able to see its associated file. Something like:
$suite->getFile(); // /path/to/test.spec.php
A change log would be handy.
Make it happen.
Peridot should minimally support JUnit XML and TAP log formats.
md in the repo? wiki? GH page?
We need to allow nested suites and a context
function.
<?php
describe("Thing", function() {
describe("Nested thing", function() {
context("The nested thing is this right now", function() {
});
});
});
Contexts are functionally equivalent to suites.
We should ditch the event emitter trait and use a single event emitter. Simplifies event handling and should make plugin/extension development easier.
$spec->addSetupFn
and $spec->addTearDownFn
need beforeEach()
and afterEach()
facades
what can actually be processed after a setup failure?
beforeEach(function() {
$this->wapper = Mockery::mock('Wrapper');
$this->writer = new Writer($this->wapper);
});
it('should write a line', function() {
$this->wapper->shouldReceive('wrap')->once();
$this->writer->write();
Mockery::close();
});
This spec will failure as my expected, because wrap() not implement.
But if I move Mockery::close() in afterEach(), it's not failure, it's not my expected.
A class responsible for loading specs
Right now the --grep
mechanism only serves as a filename filter. It might make sense to add a different option for file names and allow --grep
to match on the contents of test descriptions.
I would propose the following:
--grep
passes a regular expression to be evaluated against it
descriptions--test-suffix
option similar to PHPUnit for filtering on file namesFollowing such an error message is displayed.
The cause seems to have happened because the path of __DIR__
is different.
[RuntimeException]
Error Output: You need to set up the project dependencies using the following commands:
curl -s http://getcomposer.org/installer | php
php composer.phar install
I result that tried in 3.4.0 and 3.5.0 nightly-build It was following results.
#!/usr/bin/env php
<?php
$autoloaders = [
__DIR__ . '/../../../autoload.php',
__DIR__ . '/../vendor/autoload.php',
__DIR__ . '/vendor/autoload.php'
];
<project-path>/vendor/peridot-php/peridot/bin/../../../autoload.php
<project-path>/vendor/peridot-php/peridot/bin/../vendor/autoload.php
<project-path>/vendor/peridot-php/peridot/bin/vendor/autoload.php
<project-path>/vendor/bin/../../../autoload.php
<project-path>/vendor/bin/../vendor/autoload.php
<project-path>/vendor/bin/vendor/autoload.php
I think a good goal for Peridot 2.0 would be to further modularize peridot if possible.
Not entirely sure on execution, but it would be great if peridot-php/peridot
was a sum of core modules (core, cli, runners, concurrency?)
I think core plugins and modules would need to agree on some convention for this work - particularly with plugins, runners, etc.
Right now, they are exiting with code 0 which make travis think the tests are successful.
E.g. https://travis-ci.org/peridot-php/peridot/jobs/37307276 (hhvm build)
We should probably make time and memory usage stats available to the reporters.
Should probably profile this bad brother to check performance bottlenecks.
Would not hurt to run suites against other spec frameworks as well.
See Laravel for more details.
There is no need for Console\Application
to handle creation of the runner. It should be moved entirely to Console\Command
.
This would make changing the runner at runtime more flexible.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.