There are really two questions here: chaining and order guarantee.
Chaining is possible by calling
System.enqueueJob while inside the
execute(Queueable) method, but the documentation also states that you can't chain inside a test method (for Queueable or Batchable interfaces). There is a current limit of 2, to prevent runaway queueable code, although the blog suggests that there will be indefinite queuing in future releases with other limitations in place.
Order guarantee is not explicitly present in the documentation, although casual observation says that the ordering is presently maintained. For now, the diminishing returns of the queueable interface means that each job will be scheduled further in the future than the one before it within the same transaction, and thus will be ordered chronologically in the queue, and executed in the same order.
I wouldn't specifically depend on the 50th job executing in order, since salesforce.com hasn't specifically identified that they will be executed in order, or that the order might change based on anticipated resource consumption. In general, I would advise against writing any test method that is specifically designed to test salesforce.com's implementation. For example, it is good to write a test method that makes sure your execute method operates correctly, but bad to test the maximum limit with a hard-coded value.