Check in the analyze_sp fixtures so the suite is self-contained

analyzespTest read its four stored procedures from the parser library's SQL
corpus over a relative path, which only resolved when gsp_java happened to be
checked out beside this repository. 3384202 corrected that path, which fixed
it locally and left the tests skipping on CI, since the corpus lives under a
directory named private and is not published.

The four scripts are now in src/test/resources/sqlscripts/analyze_sp/, copied
byte for byte (cmp-verified against the corpus). That removes the sibling
requirement rather than working around it: a fresh clone with no neighbour now
runs 144 tests, 0 failures, 0 skipped. Verified by copying the tracked tree
somewhere with no gsp_java sibling and running the full suite there.

The test resolves them off the classpath rather than by relative path, so it
no longer depends on the working directory either, and fails loudly with a
named message if the resource is ever missing from the build.

src/test/resources/sqlscripts/analyze_sp/readme.md records where they came
from, what each one exercises, and that renaming anything inside them changes
the relation strings the test compares against. sample7.sql producing no
output is the assertion, not an oversight.

check-test-results.sh keeps reporting skips and still fails when everything
skipped, but nothing skips today; that guard is now for whatever gets added
next. build.yml's comment no longer describes a skip that cannot happen.

gspCommon keeps the corrected BASE_SQL_DIR for the commonTest/sqlenvTest
classes that name it. None of those run: they are lowercase testXxx.java,
which Surefire's default includes never match. Its javadoc now says to prefer
a checked-in fixture, since a checked-in fixture cannot silently resolve to
nothing, which is the failure this whole thread started from.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012qPRpoD8exYRrUmbfXXWXj

Author: 2 people

.github/scripts/check-test-results.sh

@@ -10,11 +10,10 @@
 # corrected the expected strings match the current parser's output exactly, and
 # the suite has no expected failures at all. Any failure is now a real one.
 #
-# Skips are reported rather than ignored. Tests that read the shared corpus skip
-# themselves when it is absent, which is the normal state on CI, since the
-# corpus lives in the gsp_java library repository under a directory named
-# private and is not published. A skip is therefore expected on CI and means
-# "not covered here", not "passed".
+# Skips are reported rather than ignored. Nothing skips today -- every input the
+# suite needs is checked in -- but a skip means "not covered here" rather than
+# "passed", so it is surfaced, and a run where EVERYTHING skipped fails outright
+# rather than reading as a pass.
 #
 # Usage:  .github/scripts/check-test-results.sh [surefire-reports-dir]
 #
@@ -76,8 +75,7 @@ for name, kind, msg in sorted(bad):
     print("::error::%s: %s%s" % (kind, name, (" -- " + msg[0]) if msg else ""))
 
 if skipped:
-    print("::notice::%d test(s) skipped, needing the shared SQL corpus from the "
-          "gsp_java repository (expected on CI):" % len(skipped))
+    print("::notice::%d test(s) skipped -- skipped is not passed, check why:" % len(skipped))
     for name in sorted(skipped):
         print("    %s" % name)
 

.github/workflows/build.yml

@@ -44,16 +44,12 @@ jobs:
 
       # This used to tolerate three failures in analyzespTest, believed to be
       # golden strings written for an older parser. They were something else:
-      # gspCommon.BASE_SQL_DIR pointed one level short of the shared SQL corpus,
-      # so the input file was never found and the comparison ran against an
-      # empty string. With the path corrected the suite has no expected
-      # failures, and `continue-on-error` is gone with them -- a red test run is
-      # now a red build.
-      #
-      # Those four tests skip themselves on CI, where the corpus is absent: it
-      # lives in the gsp_java repository under a directory named private and is
-      # not published. check-test-results.sh reports what was skipped and fails
-      # if everything was, so a run that proves nothing cannot read as a pass.
+      # gspCommon.BASE_SQL_DIR pointed one level short of the library's SQL
+      # corpus, so the input file was never found and the comparison ran against
+      # an empty string. Those four scripts are now checked in under
+      # src/test/resources/, so the suite is self-contained: 144 tests, no
+      # expected failures, nothing skipped. `continue-on-error` went with the
+      # threshold -- a red test run is now a red build.
       - name: Test
         run: mvn -B test
 

README.md

@@ -184,36 +184,28 @@ directories carry their own `readme.md`.
 mvn test
 ```
 
-144 tests, all passing.
-
-Four of them, in `gudusoft.gsqlparser.demosTest.analyzespTest`, read stored
-procedures from a SQL corpus that is **not in this repository**. It belongs to
-the parser library repo and is reached by a relative path, so it only resolves
-when the two sit side by side:
-
-```
-github/
-  gsp_java/          <- library, owns gsp_java_core/gsp_sqlfiles/
-  gsp_demo_java/     <- this repository
-```
-
-Without that neighbour those four **skip**, and `mvn test` still passes. The
-corpus is under a directory named `private` and is not published, so skipping
-is the normal state on CI and in a plain clone. A skip means "not covered
-here", not "passed", which is why `check-test-results.sh` lists what was
-skipped and fails if *everything* was.
-
-> **Correction.** Until 2026-07-28 this section said three of those tests
-> failed because their expected output was written for an older parser and had
-> since drifted. That was wrong, and it sent people looking at parser output
-> for a bug that was never there. `gspCommon.BASE_SQL_DIR` read
-> `../gsp_java_core/`, one level short: it named a sibling of this checkout
-> rather than the module inside `gsp_java`, so it resolved to nothing at all.
-> `Analyze_SP` never found an input file, returned an empty string, and the
-> comparison failed. The expected strings match the current parser's output
-> exactly, character for character, on all three. `testSample7` "passed"
+144 tests, all passing, nothing skipped. Every input the suite needs is in the
+repository, so a plain clone runs the whole thing.
+
+> **Correction.** Until 2026-07-28 this section said three tests in
+> `gudusoft.gsqlparser.demosTest.analyzespTest` failed because their expected
+> output was written for an older parser and had since drifted, and that they
+> were kept red on purpose as a drift signal. That was wrong, and it sent
+> people looking at parser output for a bug that was never there.
+>
+> Those tests read stored procedures from the library's SQL corpus over a
+> relative path, `gspCommon.BASE_SQL_DIR`. The path read `../gsp_java_core/`,
+> one directory level short: it named a sibling of this checkout rather than
+> the module inside `gsp_java`, so it resolved to nothing at all. `Analyze_SP`
+> never found an input file, returned an empty string, and comparing that with
+> the expected output failed. The expected strings match the current parser's
+> output exactly, character for character, on all three. `testSample7` "passed"
 > throughout only because it expects empty output, which is also what a missing
-> file produces. Fixing the path turned 3 failures into 0.
+> file produces, so it was asserting nothing.
+>
+> The four scripts now live in `src/test/resources/sqlscripts/analyze_sp/`,
+> copied byte for byte from the corpus, which removes the sibling-checkout
+> requirement rather than just correcting it. See that directory's `readme.md`.
 
 Every test here exercises a **demo** in this repository. The tests that
 exercise the *parser* live in the library, not here — see "The library-side
@@ -554,9 +546,10 @@ Three scripts under `.github/scripts/`, all runnable locally:
 - **`check-test-results.sh`** — parses the surefire XML and fails on any
   failure or error. There are no expected failures: the three that used to be
   tolerated were a wrong fixture path, not parser drift (see "Running the
-  tests"). It also lists what was skipped, and fails if *every* test was — a
+  tests"). It also lists anything skipped, and fails if *every* test was — a
   run that proved nothing should not read as a pass just because no assertion
-  got far enough to fail.
+  got far enough to fail. Nothing skips today; that guard is there for whatever
+  gets added next.
 - **`run-all-demos.sh`** — launches **every** class with a `main()`, taken from
   the compiled output so anything `pom.xml` excludes is excluded here too. It
   checks that each demo *starts*: `NoClassDefFoundError`, `NoSuchMethodError`

src/test/java/gudusoft/gsqlparser/commonTest/gspCommon.java

@@ -26,10 +26,17 @@
  * match the current parser's output exactly, character for character.
  * Corrected on 2026-07-28.
  *
- * <p>Tests reading from here must call {@link #sqlFilesAvailable()} and skip
- * themselves when it returns false. The corpus sits under a directory named
- * {@code private} and is not published, so it is absent on CI and in any clone
- * that does not also have the library checked out beside it.
+ * <p>{@code analyzespTest} no longer reads from here at all. Its four scripts
+ * were copied into {@code src/test/resources/sqlscripts/analyze_sp/}, so it runs
+ * from a plain clone with no sibling repository. **Prefer that for anything
+ * new**: a checked-in fixture cannot silently resolve to nothing.
+ *
+ * <p>What still names these constants is the {@code commonTest} and
+ * {@code sqlenvTest} classes, none of which run: they are named lowercase
+ * {@code testXxx.java}, which Surefire's default includes never match. If you
+ * ever enable one, call {@link #sqlFilesAvailable()} and skip when it returns
+ * false, because the corpus sits under a directory named {@code private}, is not
+ * published, and is absent on CI and in any clone without the library beside it.
  */
 public class gspCommon {
     public static String BASE_SQL_DIR = "../gsp_java/gsp_java_core/gsp_sqlfiles/TestCases/";

src/test/java/gudusoft/gsqlparser/demosTest/analyzespTest.java

@@ -2,40 +2,50 @@
 package gudusoft.gsqlparser.demosTest;
 
 import java.io.File;
+import java.net.URL;
 import java.util.ArrayList;
 import java.util.List;
 
-import gudusoft.gsqlparser.commonTest.gspCommon;
 import gudusoft.gsqlparser.demos.analyzesp.Analyze_SP;
 
-import org.junit.Assume;
 import org.junit.Before;
 import org.junit.Test;
 
+import static org.junit.Assert.assertNotNull;
 import static org.junit.Assert.assertTrue;
 
 /**
- * These read their input from the shared SQL corpus in the gsp_java library
- * repository, which is absent unless that repository is checked out beside this
- * one, so they skip rather than fail when it is missing. See
- * {@link gspCommon} for why, and for the path bug that made them look like
- * output drift for as long as they did.
+ * Input comes from {@code src/test/resources/sqlscripts/analyze_sp/}, so these
+ * run anywhere the repository is checked out, CI included.
  *
- * <p>JUnit 4 annotations rather than extending TestCase, deliberately:
- * Assume inside a JUnit 3 TestCase is reported by surefire as an ERROR, not as
- * a skip, so the skip would have been indistinguishable from the failure it
- * replaces.
+ * <p>They used to read the shared SQL corpus in the gsp_java library repository
+ * over a relative path, which only resolved when the two repositories sat side
+ * by side. That path was also one directory level short, so it resolved
+ * nowhere at all: no input file was found, {@code Analyze_SP} returned an empty
+ * string, and comparing that with the expected output failed. Those three
+ * failures were written up for a long time as the parser's output drifting away
+ * from stale golden strings, which they never were. The four scripts are now
+ * checked in beside the test, so there is no sibling to get wrong. See
+ * {@code src/test/resources/sqlscripts/analyze_sp/readme.md} for where they
+ * came from.
+ *
+ * <p>JUnit 4 annotations rather than extending {@code TestCase}: kept from when
+ * these skipped on a missing corpus, since {@code Assume} inside a JUnit 3
+ * {@code TestCase} is reported by surefire 2.12.4 as an error rather than a
+ * skip.
  */
 public class analyzespTest
 {
 
 	private String basedir;
 
 	@Before
-	public void setUp( )
+	public void setUp( ) throws Exception
 	{
-		Assume.assumeTrue( gspCommon.whySqlFilesMissing( ), gspCommon.sqlFilesAvailable( ) );
-		basedir = gspCommon.BASE_SQL_DIR+"private/sqlscripts/analyze_sp";
+		URL dir = analyzespTest.class.getResource( "/sqlscripts/analyze_sp" );
+		assertNotNull( "test fixtures are missing from src/test/resources/sqlscripts/analyze_sp",
+				dir );
+		basedir = new File( dir.toURI( ) ).getPath( );
 	}
 
 	@Test

src/test/resources/sqlscripts/analyze_sp/readme.md

@@ -0,0 +1,40 @@
+# analyze_sp fixtures
+
+The four SQL Server scripts here are the input for
+`gudusoft.gsqlparser.demosTest.analyzespTest`, which exercises the `analyzesp`
+demo (`Analyze_SP`) and its stored-procedure relation output.
+
+They are copied verbatim, byte for byte, from the parser library's shared test
+corpus:
+
+```
+gsp_java/gsp_java_core/gsp_sqlfiles/TestCases/private/sqlscripts/analyze_sp/
+```
+
+| file | exercises |
+|---|---|
+| `sample1.sql` | temp tables, cursors, `Create` / `Insert` / `Update` / `Read` / `Drop` relations |
+| `sample6.sql` | one table written three ways, plus a `Delete` |
+| `sample7.sql` | dynamic SQL that yields no static relations at all |
+| `sample8.sql` | joins across four tables feeding a temp table |
+
+## Why they are checked in here
+
+They used to be read from that corpus over a relative path, which only resolved
+when `gsp_java` happened to be checked out beside this repository. It also had
+the path one directory level short, so it resolved nowhere: `Analyze_SP` never
+found an input file, returned an empty string, and the comparison against the
+expected output failed. Three of these tests were red for a long time and were
+documented as the parser's output having drifted from stale golden strings.
+They had not drifted. The expected strings match the current parser's output
+exactly, character for character.
+
+Checking the scripts in removes the sibling-checkout requirement entirely, so
+the tests run on CI and in a plain clone.
+
+## Editing them
+
+The expected output in `analyzespTest` is matched exactly. Changing a table,
+column or procedure name here changes the relation strings the test compares
+against, so regenerate those in the same commit. `sample7.sql` is expected to
+produce **no** output; that is the assertion, not an oversight.

src/test/resources/sqlscripts/analyze_sp/sample1.sql

@@ -0,0 +1,101 @@
+USE [Retail]
+GO
+/****** Object:  StoredProcedure [dbo].[usp_CreateUrunIcerikForKoliKabul]    Script Date: 05/30/2012 09:56:07 ******/
+SET ANSI_NULLS ON
+GO
+SET QUOTED_IDENTIFIER ON
+GO
+ALTER proc [dbo].[usp_CreateUrunIcerikForKoliKabul] (@ProcessID bigint)    
+    
+as     
+    
+begin     
+    
+Create table #tmpKoliKabulCheck    
+(    
+ Barkod nvarchar(50),    
+ IrsaliyeNo bigint,    
+ GonderenDepo nvarchar(50),    
+ AlanDepo nvarchar(50),  
+ OkutmaTarihi nvarchar(50),  
+ OkutanKullanici nvarchar(100)  
+)    
+    
+insert into #tmpKoliKabulCheck    
+exec usp_TemaMobileParseDataForKoliKabulCheck @ProcessID, 3    
+    
+update #tmpKoliKabulCheck set Barkod = replace(Barkod, '#', '_')    
+    
+select *,    
+(select top 1 Data from dbo.fnk_Split(KoliBarkod, '_')) ToplamaId,    
+(select top 1 Data from dbo.fnk_Split(KoliBarkod, '_') order by ID desc) ToplamaKoliId    
+into #tmpCurs    
+from (    
+select UrunBarkod, KoliBarkod,     
+COUNT(UrunBarkod) as FiiliMiktar, 0 KaydiMiktar from (    
+SELECT TranData.value('(Barkod/@parentKey)[1]',    
+  'varchar(max)') AS KoliBarkod,     
+  TranData.value('(Barkod/@value)[1]',    
+  'varchar(max)') AS UrunBarkod    
+FROM tb_TemaMobileCommandTransaction where TemaMobileTransactionTipTanimRef = 1 and IsDeleted = 0
+) k     
+group by UrunBarkod, KoliBarkod    
+) x    
+where KoliBarkod in     
+(select Barkod from #tmpKoliKabulCheck)    
+
+    
+    
+DECLARE kolicursor Cursor    
+FOR     
+Select ToplamaId, ToplamaKoliId, UrunBarkod from #tmpCurs    
+open kolicursor    
+    
+declare @m_ToplamaId int    
+declare @m_ToplamaKoliId int    
+declare @m_UrunBarkod nvarchar(50)    
+    
+fetch next from kolicursor into @m_ToplamaId, @m_ToplamaKoliId, @m_UrunBarkod    
+While (@@FETCH_STATUS <> -1)    
+BEGIN    
+IF (@@FETCH_STATUS <> -2)    
+begin    
+     
+ DECLARE @Output VARCHAR(100)    
+    
+ CREATE TABLE #tmpTable    
+ (    
+  OutputValue VARCHAR(100)    
+ )    
+ INSERT INTO #tmpTable (OutputValue)    
+ EXEC usp_GetKoliInfoByBarkod @m_ToplamaId, @m_ToplamaKoliId, @m_UrunBarkod    
+    
+  if exists (select Top 1 1 from #tmpTable)  
+  begin  
+  SELECT    
+   @Output = OutputValue  
+  FROM     
+   #tmpTable    
+  end  
+  else  
+  begin  
+ set @Output = 0
+  end  
+    
+     
+ DROP TABLE #tmpTable    
+    
+ update #tmpCurs set KaydiMiktar = @Output     
+ where UrunBarkod = @m_UrunBarkod and ToplamaId = @m_ToplamaId and ToplamaKoliId = @m_ToplamaKoliId    
+end    
+    
+FETCH NEXT FROM kolicursor INTO @m_ToplamaId, @m_ToplamaKoliId, @m_UrunBarkod    
+END    
+CLOSE kolicursor    
+DEALLOCATE kolicursor    
+    
+select * from #tmpCurs  
+  
+end 
+
+