[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| Re: [jakartaee-platform-dev] [EXTERNAL] Re: TCK tests in the same repo as API andSpec | 
  
  
    Andy Guibert wrote on 2/25/20 3:52 PM:
    
      
      
        
        
        
        
          
          
             In my opinion, shell script integration "doesn't
              count".
              
              I know how to write a shell script that runs A and then
              runs B.  That's the easy part.
              
              The integration I'd like, and that we may not be able to
              achieve, is to only have to configure the TCK once - where
              is the app server, how do I deploy to it, where is the
              database server, where is the LDAP server, where will I
              find log file output, how do I configure which tests to
              run, etc.
            
          
          
          
          After speaking with some of the CTS experts in IBM, I
            would contest the claim that we currently "only have to
            configure the TCK once". 
          All of the various configs for the TCK are in one giant
            (over 2.5k lines) config file:
          
          Additionally, each spec can also define its own config
            extensions like so:
          
          
          
          I actually see it is a drawback, rather than a benefit,
            that config for the entire platform TCK is in one place. For
            example, if I just want to run the TCKs for one spec on my
            company's runtime, I'd have to sift through the entire 2.5k
            line "common" config file and configure the parts that my
            spec's TCK needs.
         
       
    
    Are you saying that you'd actually prefer to configure the same
    information 25 times when running the entire platform TCK?
    
    With one config file you can clearly organize it so that some common
    configuration comes first followed be configuration information for
    each spec.  If the configuration information is organized well, it
    should be clear what you would need to configure to run just one
    test suite.  I don't think the configuration information for each
    test suite needs to be completely independent of the configuration
    information for every other test suite in order to accomplish that.