rename job

[sharkAndshark]

Many tests failed.
The number of failed test is different on various postgis,eg
postgis 3.1

Total tests: 206 Passed: 190 Failed: 16 

postgis 3.0

Test Run Failed. Total tests: 206 Passed: 204 Failed: 2 

postgis 2.5

Total tests: 206 Passed: 195 Failed: 11 

The test log is like

 Stack Trace: at LinqToDBPostGisNetTopologySuite.Tests.SpatialReferenceSystemFunctionsTests.TestSTSetSrId() in /home/runner/work/linq2db-postgis-extensions/linq2db-postgis-extensions/LinqToDBPostGisNetTopologySuite.Tests/SpatialReferenceSystemFunctionsTests.cs:line 35 X TestSTTransform [39ms] Error Message: Expected string length 185 but was 193. Strings differ at index 42. Expected: "....1776848522251 42.3902896512902,-71.1776843766326 42.39038..." But was: "....1776848522251 42.39028965129018,-71.17768437663261 42.390..." 

[apdevelop]

Many tests failed.

OK, will try to fix them.. there are mostly floating point rounding issues.

[apdevelop]

Done with 3.0 / 3.1.
There are still several issues on PostGIS 2.5... probably need to perform some investigations.

[sharkAndshark]

ST_3DLineInterpolatePoint seems only be supported on postgis.version >= 3.0.

 Error Message: Npgsql.PostgresException : 42883: function st_3dlineinterpolatepoint(geometry, numeric) does not exist Data: Severity: ERROR InvariantSeverity: ERROR SqlState: 42883 MessageText: function st_3dlineinterpolatepoint(geometry, numeric) does not exist Hint: No function matches the given name and argument types. You might need to add explicit type casts. Position: 9 File: parse_func.c Line: 614 Routine: ParseFuncOrColumn 

Is there some attribution in NUnit can divide tests into different groups with a strategy like blacklist,eg [NotSupportOn3.0][NotSupportOn3.1],then we can test them separately in workflow's yml files?
Maybe blacklist strategy is good ?

[apdevelop]

Is there some attribution in NUnit

Probably yes, something like Platform attribute
which should check argument value (PostGIS version, like 3.0.0 ) , passed from top level script
On methods like ST_3DLineInterpolatePoint that attribute should be added to ignore tests if version not match.
Like [MinVersion(3.0.0)] ; if no attribute provided, will test on any versions.

[sharkAndshark]

Seems the category attribution is the one.
There is a filter option in dotnet test CLI.

Still no idea how to do it.😂

[sharkAndshark]

Some ideas here:
Strategy A
There are three attributes:
[TestGroup(NotSupportOn2.5)],[TestGroup(NotSupportOn3.0)],[TestGroup(NotSupportOn3.1)]
Add these attributions to several test method.
Then run CLI commands:

dotnet test --filter TestCategory!~NotSupportOn2.5

dotnet test --filter TestCategory!~NotSupportOn3.0

dotnet test --filter TestCategory!~NotSupportOn3.1

Strategy B
There are three attributes:
[TestGroup(MinVersion2.5)],[TestGroup(MinVersion3.0)],[TestGroup(MinVersion3.1)]
Add these attributions to every test class/method,then run CLI commands:

dotnet test --filter TestCategory=MinVersion2.5

dotnet test --filter TestCategory=MinVersion3.0

dotnet test --filter TestCategory=MinVersion3.1

[apdevelop]

How about:
[Category("MinVersion3.0")]
for several tests for PosGIS 3.0 and higher

Run for 2.5, exclude 3.0 tests: (is there a method to exclude both 3.0, 3.1 using 'contains string' expression ?)
dotnet test --filter TestCategory!~MinVersion3.0

[sharkAndshark]

How about:
[Category("MinVersion3.0")]
for several tests for PosGIS 3.0 and higher

Run for 2.5, exclude 3.0 tests: (is there a method to exclude both 3.0, 3.1 using 'contains string' expression ?)
dotnet test --filter TestCategory!~MinVersion3.0

OK.😀

[sharkAndshark]

Problem here.
PostGIS 2.5 does not support auto casting from string like wkt to geometry types.
eg.

select st_envelope("wkt here balabalalba...") will be failed in PostGIS 2.5 but succeed in PostGIS 3.x.

This feature will split all tests to two parts with duplicated code.(Actually many tests in PostGIS 2.5 failed beacause this)

So is there one way can add this feature without duplicated unit test?
I like this feature.
@apdevelop

[apdevelop]

There is another possible solution: drop tests for PostGIS 2.x at this moment and focus on extending support for 3.x (there is 3.1 version already). The 3.0 version is mentioned in README
The actual problem isn't only failed tests, there are no hints of PostGIS version support on the library method themselves.
There is PostGIS 1.5 legacy support in separate project

[sharkAndshark]

Agree. There are so many methods not implemented in pg3.x.