I like the second one more

It's good idea however there is no reason why developer cannot wrap add_employee,add_location etc. into single package add_data and call it beforetest.

But second one looks a bit cleaner and more readable as well.

We could also allow stacked form for --%beforeall and --%beforeeach
Currently we take only the last one if several are defined in single package.
I think we should either allow all of those (stacked and ordered by position in package spec) or we should print a warning that --%beforeall was ignored(overwritten) by next declaration of --%beforeall

I think that should be a syntax error or warning at least. If before all means to be executed before all elements of the suite then having more than one creates a bit of confusion. E.g. in which order beforeall will run and if something run before it is no longer before all.
I believe that should be allowed to be defined once only to keep the meaning of that annotation.

@lwasylow RSpec allows multiple before blocks and each of them gets executed in the order thye were defined within the context.
The beforeall means before all tests (within context), not before all items.

On the other hand, as you said, one can always stack/combine multiple procedures into --%beforeall procedure.
The multiple --%beforeall seems of much lesser value than multiple/multivalue --%beforetest
The only real value of multiple --%beforeall would be for completeness and consistency as well as to have clear and easy answer to: What if I have two --%beforeall in my test package.

Currently if you have several --%beforeall the last one defined in package spec is executed. This is a bit counter-intuitive as no warning or error is displayed.
I personally prefer to allow more than introduce limitations, just because I don't see a clear use-case for multiple --%beforeall annotations.

This is moved to separate issue: #649
So the original issue (Multiple (stacked) --%beforetest) can be more contained.

After having a bit more thought on the topic I'd like to suggest the following to the beforetest, aftertest

• add ability to reference procedures from other packages
• add ability to call multiple procedures

Additionally, beforeall, afterall, beforeeach, aftereach, we could be suite level annotations with similar syntax as beforetest/aftertest.
Example below:

package test_departments_api is

  --%suite(Departments API)
  --%beforeall(common_data_helper.data_setup, privileges_helper.setup)
  --%afterall(privileges_helper.cleanup, common_data_helper.data_cleanup)


  procedure setup_manager;

  --%test(Adds department)
  --%beforetest(some_package.add_employee, some_package.add_location, setup_manager)
  procedure successfully_add_department;

  --%test(Fails to add depatrment when no manager found)
  --%beforetest(common_employee_helper.setup_employee, common_location_helper.setup_location)
  procedure fail_to_add_department;

  --%test(Returns department by name)
  --%beforetest(common_department_helper.setup_depatment)
  procedure get_department_by_name;

end;

This way, we can allow for even better separation of common things.
It is still possible to achieve the same without before/after annotations referencing procedures outside of package, but it requires a lot of bolierplate code as below.

package test_departments_api is

  --%suite(Departments API)

  --%beforeall
  procedure common_setup;
  
  --%afterall
  procedure common_cleanup;

  procedure setup_manager;

  --%test(Adds department)
  --%beforetest(some_package.add_employee, some_package.add_location, setup_manager)
  procedure successfully_add_department;

  --%test(Fails to add depatrment when no manager found)
  --%beforetest(common_employee_helper.setup_employee, common_location_helper.setup_location)
  procedure fail_to_add_department;

  --%test(Returns department by name)
  --%beforetest(common_department_helper.setup_depatment)
  procedure get_department_by_name;

end;
/
...
package body test_departments_api is

  procedure common_setup is
  begin
    common_data_helper.data_setup;
    privileges_helper.setup;
  end;

  procedure common_cleanup is
  begin
    privileges_helper.cleanup;
    common_data_helper.data_cleanup;
  end;

...

Would it make sence and add value to have this kind of flexibility in annotations?

The down side I see is that we would only know at runtime if the dependencies to other packages defined by before/after are valid.

i like this.. mainly because i just tried to do it and didnt understand why it didnt work

i would suggest to add it to --%beforeall also for consistency

I also like the idea of being able to refer to other packages.

I was thinking of the same