google / grinder.dart Goto Github PK

Integrate the Dart Test Runner (https://github.com/google/test_runner.dart) in some way.

-rwxr-xr-x 1 root root 229 Nov 10 16:38 ex.sh

run `copyFile(new File('./ex.sh'), new Directory('./foo'));

result is

-rw-r--r-- 1 root root 229 Nov 10 16:48 ex.sh

which doesn't have execute permission.

deleteEntity(new Directory('path')) is a bit verbose. What do you think about delete(string_or_directory) ?

Wanted to publish grinder 0.6 but I don't have uploader priv's. Can you add [email protected] ? Thanks!

It could:

• determine if content_shell was installed
• download it
• run it

sethladd@sethladd-macbookair ~/Code/stagehand (super-simple-webapp)$ grinder --version
Unhandled exception:
FormatException: Could not find an option named "version".

Would love a --version :)

For an example :)

Can we defer to pub build ?

That would work when run from within the grinder package itself, but from other packages it needs to be:

pub run grinder:grind

However, IMO pub run grinder should work, see:

https://dartbug.com/22129

Currently, the latest version of Grinder (0.6.0) is incompatible with Angular.dart (and its modules, such as di). The cause is that angular is using a version of the analyzer which depends on an older version of the args package.

Apparently, Grinder is not affected by the changes made on newer versions of the args package, so it would be safe to use a wider version constraint, like the one used by the Polymer package:

args: '>=0.10.0 <0.13.0'

Figure out if grinder should have a code coverage task directly, or use a test runner (TBD), that provides a way to generate code coverage.

Seems like all the functions in PubTools are really like static assets. Did we consider either a library for PubTools and top-level functions or actual static methods on the PubTools.

I went looking for how to invoke pub build and instantiating an instance of PubTools just to run build seems overkill. But maybe I'm missing something.

Tracking issue for releasing 0.6. Let's bunch up API breaking changes (we already have a few committed).

@sethladd

This is the same as #14 but for when a task returns a future. The logs were still printing exceptions undesirably.

When a task fails and calls context.fail("Tests Failed!"); exceptions get printed to the stdout/log. We are constantly scrolling up past a stack trace to see the actual failure message. This is unnecessary output, if a task is failing for a known quantity that task should log necessary remarks and call fail. The exception masks the real problem.

Example output we are seeing:

dart tool\grinder.dart test

...

6 PASSED, 1 FAILED, 0 ERRORS
Unhandled exception:
Exception: Some tests failed.
#0 SimpleConfiguration.onDone (package:unittest/src/simple_configuration.dart:189:9)
#1 _completeTests (package:unittest/unittest.dart:487:17)
#2 _runTest (package:unittest/unittest.dart:436:19)
#3 _nextTestCase (package:unittest/unittest.dart:376:11)
#4 _asyncRunCallbackLoop (dart:async/schedule_microtask.dart:23)
#5 _asyncRunCallback (dart:async/schedule_microtask.dart:32)
#6 _asyncRunCallback (dart:async/schedule_microtask.dart:36)
#7 _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:128)

Uncaught Error: GrinderException: Tests Failed!
Stack Trace:
#0 GrinderContext.fail (package:grinder/grinder.dart:169:32)
#1 GrinderAutomatedTestTask._runTestProcess (package:grinder_automated_test_task/grinder_automated_test_task.dart:98:19)
#2 runTests (package:grinder_automated_test_task/grinder_automated_test_task.dart:40:20)
#3 GrinderTask.execute (package:grinder/grinder.dart:202:26)
#4 Grinder._executeTask (package:grinder/grinder.dart:337:30)
#5 Grinder.start. (package:grinder/grinder.dart:312:28)
#6 Future.forEach.nextElement. (dart:async/future.dart:300)
#7 Future.Future.sync (dart:async/future.dart:168)
#8 Future.forEach.nextElement (dart:async/future.dart:300)
#9 _rootRunUnary (dart:async/zone.dart:730)
#10 _RootZone.runUnary (dart:async/zone.dart:864)
#11 _Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:488)
#12 _Future._propagateToListeners (dart:async/future_impl.dart:571)
#13 _Future._completeWithValue (dart:async/future_impl.dart:331)
#14 _Future._asyncComplete. (dart:async/future_impl.dart:393)
#15 _asyncRunCallbackLoop (dart:async/schedule_microtask.dart:23)
#16 _asyncRunCallback (dart:async/schedule_microtask.dart:32)
#17 _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:128)

Unhandled exception:
GrinderException: Tests Failed!
#0 _rootHandleUncaughtError.. (dart:async/zone.dart:713)
#1 _asyncRunCallbackLoop (dart:async/schedule_microtask.dart:23)
#2 _asyncRunCallback (dart:async/schedule_microtask.dart:32)
#3 _asyncRunCallback (dart:async/schedule_microtask.dart:36)
#4 _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:128)

Since this package depends on $DART_SDK to be set it should throw an error when its not.

Could we get away with not requiring DART_SDK to use grinder? I just tried to run it on stagehand, and I got this:

~/Code/stagehand[website*]$ ./grind build-site
grinder running [init] [build-site]

[init]

[build-site]
  Building the site
GrinderException: Unable to locate the Dart SDK; try setting the DART_SDK environment variable.
#0      runSdkBinary (package:grinder/grinder_utils.dart:139:5)
#1      PubTools.build (package:grinder/grinder_utils.dart:226:17)
#2      buildSite (file:///Users/sethladd/Code/stagehand/tool/grind.dart:74:12)
#3      GrinderTask.execute (package:grinder/grinder.dart:213:49)
#4      Grinder._executeTask (package:grinder/grinder.dart:351:30)
#5      Grinder.start.<anonymous closure> (package:grinder/grinder.dart:322:28)
#6      Future.forEach.<anonymous closure>.<anonymous closure> (dart:async/future.dart:302)
#7      Future.Future.sync (dart:async/future.dart:168)
#8      Future.forEach.<anonymous closure> (dart:async/future.dart:302)
#9      Future.Future.sync (dart:async/future.dart:168)
#10     Future.doWhile.<anonymous closure> (dart:async/future.dart:327)
#11     _RootZone.runUnaryGuarded (dart:async/zone.dart:1020)
#12     _RootZone.bindUnaryCallback.<anonymous closure> (dart:async/zone.dart:1049)
#13     _RootZone.runUnary (dart:async/zone.dart:1082)
#14     _Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:488)
#15     _Future._propagateToListeners (dart:async/future_impl.dart:571)
#16     _Future._completeWithValue (dart:async/future_impl.dart:331)
#17     _Future._asyncComplete.<anonymous closure> (dart:async/future_impl.dart:393)
#18     _asyncRunCallbackLoop (dart:async/schedule_microtask.dart:41)
#19     _asyncRunCallback (dart:async/schedule_microtask.dart:48)
#20     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:126)

Dart and the SDK is on my path. Is that enough to find pub?

Currently global is the only instance field on Pub, so you have to do new Pub().global.run(..). I think it was inteneded to be static so you can do Pub.global.run(..).

The convention for the bin and tool scripts is poorly explained and it took me some tinkering before I was able to run tests using pub run grinder tests.

I'm using grinder from office as substitute of bash script. I'm happy that I don't need to know bash grammer.

OK, the only unhappy thing is ...

Currently, grider sort tasks as alpabetical order. https://github.com/google/grinder.dart/blob/master/lib/grinder.dart#L128

How about listing tasks as they defined? From the example1.
If we define tasks as below.

  task('init', init);
  task('compile', compile, ['init']);
  task('deploy', deploy, ['compile']);
  task('all', null, ['deploy']);

then we get

valid targest:
  [init]
  [compile]
  [deploy]
  [all]

• More convenient
• Less grinder lock in effect

It would be cool to do:

stagehand ...
den install grinder
pub run grinder:init

To initialize a grinder project. init would probably not need to be in executables, it would initialize a default tool/grind(er).dart script.

We should see if these are necessary, and/or adversely affect windows installs which are already working.

defaultInit() would verify that it's run from a project dir

defaultClean() would delete the build/ dir if it existed.

#66

From customer: "when running something like PubTools.build() doesn’t output anything until the entire job is done. So when a build takes 60 seconds, and there isn’t any sort of output it’s not clear that something is going on. It’s even worse with something like pub serve that doesn’t ever finish so there is never any output."

https://github.com/seaneagan/which.dart

I think we want to promote a convention like:

cd my_package
pub run grind

or

pub run grind test

We can assume pub will eventually let us install a script into the PATH, so we'll eventually get:

grind test

This implies there is some sort of grinder_config.dart file in a package, that the grinder util looks for.

Switching from drone to travis means PRs will be tested

After a sufficient number of PRs, that is :)

build() has it, but get() doesn't, e.g.

Most build tools allow setting a default target/goal/task:

https://github.com/gulpjs/gulp/
http://gruntjs.com/creating-tasks
http://www.gnu.org/software/make/manual/make.html#Goals

which would allow new devs on the project to just run grind, without needing to know what targets the project supports.

Also, it would be cool if the default drone.io or travis script were just:

pub get
pub run grinder

so then you wouldn't need to configure it at all.

Improve coverage: https://coveralls.io/builds/1639281.

Right now we have defineTask('compile', taskFunction: compile, depends: ['init']);

Let's see if we can shorten that up:

var init = task(init);
var compile = task(compile, [init]);

Benefits:

We reduce the amounts of strings in the system... this enables better code completion and warnings/errors.

Less typing.

Dependencies are checked by the analyzer now.

Still 0.5.7 is latest from https://pub.dartlang.org/packages/grinder