Add integration tests for the execution domain.

pkg/analyzer_plugin/test/integration/support/integration_tests.dart

 // Copyright (c) 2017, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 import 'dart:async';
 import 'dart:collection';
 import 'dart:convert';
 import 'dart:io';
 
 import 'package:analyzer_plugin/protocol/protocol_generated.dart';
@@ skipping 540 matching lines @@
       if (messageAsMap.containsKey('id')) {
         outOfTestExpect(messageAsMap['id'], isString);
         String id = message['id'];
         Completer completer = _pendingCommands[id];
         if (completer == null) {
           fail('Unexpected response from server: id=$id');
         } else {
           _pendingCommands.remove(id);
         }
         if (messageAsMap.containsKey('error')) {
-          // TODO(paulberry): propagate the error info to the completer.
-          completer.completeError(new UnimplementedError(
-              'Server responded with an error: ${JSON.encode(message)}'));
+          completer.completeError(messageAsMap['error']);

[Paul Berry, 2017/02/12 14:39:04]

Hmm, when did this code get duplicated?  We should probably de-dup these files.

(Not necessary to fix for this CL; just thought I would mention it in case
anyone remembers the reason for the code duplication).

[Brian Wilkerson, 2017/02/12 16:41:54]

It was duplicated when I created the analyzer_plugin package.

As unfortunate as the duplication is, we can't avoid all of the duplication
because this file is referencing classes from the analyzer_plugin's protocol and
the other file is referencing classes from the analysis_server's protocol, and
the two sets of classes are distinct. It might be worth unifying portions of
them at some point, but that depends on how much could be unified.

In the interest of full disclosure, there are other libraries that were also
duplicated and I'm much more interested in deduplicating those at some point.
But I'll note that the shape of the plugin protocol is still changing and I
would prefer to finish defining it before attempting any deduplication.

[devoncarew, 2017/02/12 17:52:34]

Is it important to keep this files in sync? If so, perhaps we should add some
comments to that effect at the top of both files.

[Brian Wilkerson, 2017/02/12 18:47:09]

That depends on what you mean by "important". :-)

It is, of course, a good engineering practice to avoid duplicating code when
possible, but the files are dealing with two separate, albeit similar,
protocols. It isn't a requirement that the protocols remain the same over time
(and they are already different in minor ways), so while I wouldn't say it's
critical, and I think it's less important than getting the plugin support
finished, I think it is important on some level.

         } else {
           completer.complete(messageAsMap['result']);
         }
         // Check that the message is well-formed.  We do this after calling
         // completer.complete() or completer.completeError() so that we don't
         // stall the test in the event of an error.
         outOfTestExpect(message, isResponse);
       } else {
         // Message is a notification.  It should have an event and possibly
         // params.
@@ skipping 367 matching lines @@
   void populateMismatches(item, List<MismatchDescriber> mismatches);
 
   /**
    * Create a [MismatchDescriber] describing a mismatch with a simple string.
    */
   MismatchDescriber simpleDescription(String description) =>
       (Description mismatchDescription) {
         mismatchDescription.add(description);
       };
 }