Saturday 27 July 2013

Week 8 - ZestLoops development and improvements

8th week over... This week I continued on development of ZestLoops. Unfortunately some problems with serialization/deserialization with gson forced me to edit the previous code, and to differentiate loops  between String and Integer values.
This change allows also a better representation of Loops based on Integers value (i.e. in the form "FOR i FROM 0 TO 10000000" ): in fact, the previous code consisted on the creation of a set of integers between 0 and 10000000 (westfulness).
The new design splits the representation of Loops based on Strings (which uses more or less the previous code) and the one based on Integers; this second type only persists the State of the loop, i.e. the start value, the current value and the final one (in the example above, at step 5, only the values 0,5 and 10000000 are persisted).

This representation was discarded in the previous Loop code, because it didn't allowed loops of the form "FOR token IN [1,2,3,5,6,4,8,9]". After a chat with the mentor, we decided to represent this last type of loop as a ZestLoop based on String instead of Integers. The main reason of this decision is the following: such loop type could be used only if an user wants to take the value and put it inside the request/response. For this reason it is reasonable to interpret these values as Strings.

This week I also performed some tests on the previous code. Tests seem to work and passed also after the changes made!

I hope to be able to push the definitive code in few days!

Thursday 18 July 2013

Week 7 - ZestComplexConditional & ZestLoop

7th week is over. First official commit done!
Here the code :)

ZestStructuredConditional manages Structured conditionals.

How does it work?

The main idea was to create a load of expression types (based on REGEX, status code, URL, ...). Each ZestElement which needs to evaluate a list of expression build a StructuredExpression (which is an AND/OR of a list of other expressions). The mechanism is very simple: once the StructuredExpression had been built, the evaluation calls the method evaluate for each sub-expression. In this way an Expression Tree is built, and the evaluation mechanism works recalling the evaluation for each leaf; each internal node, which is an AND/OR expression, collect all the results of the children and compute an AND/OR evaluation of the boolean received by the children; the root will then return the value of the whole expression.

All tests of this work can be found in the official repo.

ZestLoop

Next task is a bit more tricky. Now Zest does not allow to use loop... I started developing this feature creating a new class: ZestLoop. This class should represent a particular statement which is a container of other statements.
I created a first draft of design and I started implementing how it should work. All the code I'm writing can be found in my repo

By the way, the current implementation is not really good. The biggest problem I found is that this does not separate the runner from the code: the current realization must have a reference to the whole Script and to the Runner. Loops are still under design phase, so I plan to solve this issue next week and, maybe, to make another pull request. :)

Here a snapshot of the UML of the current implementation:



Friday 12 July 2013

Week 6 - Editing Zest Complex Conditional

This is the sixth week: the exam session is about to finish.
This week I worked on the code I wrote last week following some comments and suggesions from the mentor.
Most important point were:
  • Creation of a new class: ZestStructuredExpression;
  • Modified inheritance of classes
the previous two points were to avoid code duplication for the ZestExpression[And,Or]. The current structure is the following:

  • Developed the code of the method deepCopy for all the new classes.
Last week I didn't wrote this method.
  • Made some structural changes (e.g. deleted the reference to the parent of a conditional, the name, ...).
Next week is reserved for tests and, maybe, I'll try to integrate it at the ZAP side.

Friday 5 July 2013

Week 5 - ZAProxy & Zest Complex Conditional

During 5th week I found a bug I what I developed last week. I started trying to solve the issue, but after some time spent on that problem, the mentor and I decided to start developing on Zest side: Complex Conditional.

Ref: https://docs.google.com/document/d/1oAx26AU5gs4WKVXeI1pQF-sC-B9CiVXd7R3PDz7Sikw/edit#heading=h.xgiwfxe7dwpf

The structure I came up now is this:


  • ZestConditional
  • ZestBooleanAnd
    • ZestBooleanOr
      • ZestExpressionRegex (regex exp1)
      • ZestExpressionRegex (regex exp2)
    • ZestBooleanStatusCode (200)
  • List <ZestStatement> ifStatements etc...
    Going more inside, I designed the following internal structure for each class/interface:
  • abstract class ZestExpression extends ZestElement implements ZestConditionalElement:
    • List<ZestConditionalElement> children;
    • boolean not;
    • ZestConditionalElement parent;
    • String name;
    • static int counter; // for the default name
    • abstract boolean evaluate;
  • class ZestConditional extends ZestStatement implements ZestContainer, ZestConditionalElement:
    • List<ZestConditionalElement> children;
    • List<ZestStatement> ifStatement;
    • List<ZestStatement> elseStatement;
  • class ZestBoolean[And,Or] extends ZestExpression implements ZestConditionalElement:
    • ZestConditionalElement parent;
    • List<ZestConditionalElement> children;
    • boolean evaluate();
  • interface ZestConditionalElement extends ZestContainer
    • getIndex(); //return the index of the statement;
    • getChildren();// returns the children;
    • isLeaf();//true if it has no children;
    • isRoot();// if it is the root of the Conditional Tree
    • evaluate();// evaluate the whole condition.


The structure above had been implemented and the javadoc is done, and this a basic UML:




And here you can find my fork of the Zest repo (with the structure developed): https://github.com/Vankar/zest


Some tests has started (very basic and not checked in).

Note the assumption: 
2 Expression of the same class can have the same name!

Any comment, tip or advice on the Structure of the Complex Conditional is greatfully welcome :)