Menu

#10 Rework assertion framework for easier extensibility

v1.3
closed
None
v1.1
not_relevant
Enhancement_Request
Framework
3-moderate
2021-05-24
2012-07-11
No

Now, logic for assertions and their rendering in reports is distributed in an number of macros, making it difficult to write new assertions.

Therefore, the logic for assertions should be reorganized in an IoC manner (see inversion of control). Every assertion has to provide a set of macros with standardized tasks and interfaces.

This also affects the report rendering process. A more thorough refactoring of the reporting process, enabling also reports in various report formats, is being addressed in [bugs:#11].

The new logic should be as follows, for every assertion:

  • Macro assert<assert symbol> (<assert symbol> is the unique name of the assert, only letters A-Z, for instance assertequals where <assert symbol>=equals):
    • Determine test result by comparing actual outcome to expected outcome
    • write results to test database by calling _sasunit_asserts
    • optionally (only if additional test results should be saved and used for later reporting, see _sasunit_renderreport...): create a unique named subfolder of the tst folder and copy there unformatted(!) objects under their original name. Follow strict naming conventions for the subfolder: _<scenario-id>_<case-id>_<seq. number>_<assert symbol>)
  • optionally (only if additional reports should be generated, for instance the table listing of assertcolumn): macro _sasunit_renderreport_<assert symbol> renders additional report components. Should take a format parameter which specifies the report format, in the first step only HTML possible.

  • optionally (only if addtional information should be written to the listing of test results per test case): macro _sasunit_renderassert_<assert symbol> renders entry into test detail table (now part of _sasunit_reportdetailhtml). If not present: default rendering just writes out results from the database. Should take a format parameter which specifies the report format, in the first step only HTML possible.

Related

Tickets: #11
Tickets: #116
Tickets: #55

Discussion

  • Andreas Mangold

    Andreas Mangold - 2013-02-05
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -2,7 +2,7 @@
    
     Therefore, the logic for assertions should be reorganized in an IoC manner (see [inversion of control](http://www.analytical-software.de/en/knowledge-library/papers/ioc-for-sas-macro/)). Every assertion has to provide a set of macros with standardized tasks and interfaces. 
    
    -This also affects the report rendering process. A more thorough refactoring of the reporting process, enabling also reports in various report formats, is being addressed in [ticket:#11].
    +This also affects the report rendering process. A more thorough refactoring of the reporting process, enabling also reports in various report formats, is being addressed in [bugs:#11].
    
     The new logic should be as follows, for every assertion: 
    
     
  • Andreas Mangold

    Andreas Mangold - 2013-02-05
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -6,9 +6,9 @@
    
     The new logic should be as follows, for every assertion: 
    
    -* Macro **assert**\<**assert symbol**\> (\<assert symbol\> is the unique name of the assert, only letters A-Z, for instance assertequals where \<assert symbol\>=equals):
    +* Macro **assert**<**assert symbol**\> (<assert symbol\> is the unique name of the assert, only letters A-Z, for instance assertequals where <assert symbol\>=equals):
         * Determine test result by comparing actual outcome to expected outcome
         * write results to test database by calling \_sasunit_asserts
    -    * optionally (only if additional test results should be saved and used for later reporting, see \_sasunit_renderreport...): create a unique named subfolder of the tst folder and copy there unformatted(!) objects under their original name. Follow strict naming conventions for the subfolder: _\<scenario-id\>\_\<case-id\>\_\<seq. number\>\_\<assert symbol\>)
    -* optionally (only if additional reports should be generated, for instance the table listing of assertcolumn): macro **\_sasunit\_renderreport\_\<assert symbol\>** renders additional report components. Should take a format parameter which specifies the report format, in the first step only HTML possible.<br><br>
    -* optionally (only if addtional information should be written to the listing of test results per test case): macro **\_sasunit\_renderassert\_\<assert symbol\>** renders entry into test detail table (now part of \_sasunit\_reportdetailhtml). If not present: default rendering just writes out results from the database. Should take a format parameter which specifies the report format, in the first step only HTML possible.
    +    * optionally (only if additional test results should be saved and used for later reporting, see \_sasunit_renderreport...): create a unique named subfolder of the tst folder and copy there unformatted(!) objects under their original name. Follow strict naming conventions for the subfolder: _<scenario-id\>\_<case-id\>\_<seq. number\>\_<assert symbol\>)
    +* optionally (only if additional reports should be generated, for instance the table listing of assertcolumn): macro \_**sasunit**\_**renderreport**\_<**assert symbol**\> renders additional report components. Should take a format parameter which specifies the report format, in the first step only HTML possible.<br><br>
    +* optionally (only if addtional information should be written to the listing of test results per test case): macro **\_sasunit\_renderassert\_<assert symbol\>** renders entry into test detail table (now part of \_sasunit\_reportdetailhtml). If not present: default rendering just writes out results from the database. Should take a format parameter which specifies the report format, in the first step only HTML possible.
    
     
  • Klaus Landwich

    Klaus Landwich - 2013-05-27

    Implemetation is slightly different to this concept. Asserttype is stored in the test database as "assertXxxxxx" e.g. "assertEquals".

    To avoid text scanning the naming convention is changed. The rendering for an assert is also divided into two separate macros. One for the expected and one for the actual values.

    Naming convention for rendering actual and expected values was _sasunit_renderassert_<assert symbol> and now is _sasunit_render_<assert symbol>Act or _sasunit_render_<assert symbol>Exp respectively.

    Naming convention for rendering assert report was _sasunit_renderreport_<assert symbol> and now is _sasunit_render_<assert symbol>Rep

    We got an issue with the length of some asserts. assertPerformance exceeds maximum length of 32 characters when using the above naming convention.

    To fix this issue the macros wil be renamed. There is already an corresponding ticket.

     
  • Klaus Landwich

    Klaus Landwich - 2013-08-04
    • status: accepted --> closed
     
  • Klaus Landwich

    Klaus Landwich - 2013-08-04

    Reworking is done and ODS for HTML is already implemented

     

Anonymous
Anonymous

Add attachments
Cancel