Testing Qt Code which requires EventHandling and UI about cucumber-cpp HOT 3 OPEN

QtWireProtocolHandler.zip

Idea / Solution is to implement and use a Qt based WireProtocolServer

in the main of the test applikation:

  // initialize qt base wire protocol server
  QtWireProtocolHandler wire_protocol_handler( listenHost, port, parser.isSet( "verbose" ) );
  // start processung
  wire_protocol_handler.process();
  // run qt eventloop in main thread
  return app.exec();

Implementations (attached as zip)

class QtWireProtocolHandler : public QObject
{
  Q_OBJECT
public:
  explicit QtWireProtocolHandler( const std::string& host, int port, bool verbose );
  ~QtWireProtocolHandler() override;
  void process();
protected slots:
  void onClose();

private:
  std::unique_ptr<CukeEngineImpl>       cukeEngine      = nullptr;
  std::unique_ptr<JsonWireMessageCodec> wireCodec       = nullptr;
  std::unique_ptr<WireProtocolHandler>  protocolHandler = nullptr;
  std::unique_ptr<SocketServer> server = nullptr;
  bool                                  verbose         = false;
};

Which uses a custom Implementation of SocketServer

class QtTCPSocketServer : public QObject, public SocketServer
{
  Q_OBJECT
public:
  typedef unsigned short port_type;
  explicit QtTCPSocketServer( const ProtocolHandler* protocolHandler );

  void listen( const port_type port );
 void listen( const asio::ip::tcp::endpoint endpoint );

  asio::ip::tcp::endpoint listenEndpoint() const;

  void acceptOnce() override;

signals:
  void closed();

private:
  void doAcceptOnce( asio::basic_socket_acceptor<asio::ip::tcp>& acceptor );
  void timerEvent( QTimerEvent* ) override;

  asio::ip::tcp::acceptor            acceptor;
  std::unique_ptr<AsyncStreamReader> mAsyncStreamReader = nullptr;
  asio::ip::tcp::iostream            mStream;
};

from cucumber-cpp.

@kreuzberger I strongly recommend to not include the Qt classes nor UI in the acceptance tests. And not timer, you don't want to make your tests slower than needed. Only include and test the business logic of the application. When doing so, you probably don't need the event handling. This removes asynchronous (non-deterministic) behavior, making the tests stable.

I had cases where we had queues (in Qt this would be queued connections) in the code under test. The solution was to dispatch the stuff in the queue until empty after every step. I think it was with QEventLoop::processEvents within AFTER_STEP hook. Or something like here.

from cucumber-cpp.

I agree with most of your doubts. Testing with no such constraints make live easier. Main advantage of the gherkin language is for me still to test user scenarios (not the gui) but if the app under the test is a rich desktop qt app and runs in a multi process enviroment i have to face it. Or use Squish. But testing the logic with squish is much more slower and complicated i think. But this is currently my intention, test the app instead of squish/gherkin with a different (and maybe better) approach.

But back to the questions:

• The existence of a nomain library is for me the hint that this library could be used.
• The names and used classes have an "internal" namespace, but if used as static library i can access them without any problems. The CUCUMBER_CPP_EXPORT is a hint for me that the classes could be used as an API even if builded as shared libraries?

from cucumber-cpp.