dataforgoodfr / dataforgoodfr/Coordonnees

[Coordo Backend] Chore - Add regression tests for current layer and style generation logic

Open
#2 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

coordo-py
Dominant language
Python
Stars
6
Forks
0
PR merge metrics
No merged PRs in 30d

Description

The purpose of this task is to write regression tests for the existing implementation.

Testing Strategy
1. Style endpoint response tests
  • Test that the style view:

    • Returns valid JSON

    • Contains required top-level keys:

      • version
      • sources
      • layers
      • metadata
  • Assert that:

    • version is set to 8
    • metadata.controls matches the configuration

2. Source generation tests

For each configured layer type, assert that the expected sources are created:

  • XYZ services

    • A raster source is created
    • The source contains a tiles array
    • The provider name is used as the source key
  • OpenMapTiles

    • A vector source named openmaptiles exists
    • The source URL is correctly set
    • The source is created only once even if multiple layers use it
  • SQL / GeoJSON

    • A GeoJSON source is created for the table
    • The source type is geojson
    • The data field contains a valid GeoJSON FeatureCollection

3. Layer definition tests

Validate the generated layer entries:

  • Each configured layer:

    • Has a unique id
    • Has a type
    • References an existing source
    • Preserves custom styles (paint, layout, etc.) when provided
  • OpenMapTiles layers:

    • Contain a source-layer
    • Contain the expected filter structure
  • SQL layers:

    • Use the circle layer type (or any value of an enum which should be created to list all the types available for the SQL layers
    • Reference the GeoJSON source by table name

4. Popup metadata tests
  • Layers with a popup configuration:

    • Contain a metadata.popup field
    • Preserve the popup configuration as-is
  • Layers without a popup:

    • Do not contain a metadata.popup entry

5. SQL aggregation and GeoJSON structure tests

At a high level (no database-heavy assertions):

  • The generated GeoJSON:

    • Is a FeatureCollection
    • Contains only Point geometries ((or any value of an enum which should be created to list all the geometries available
    • Includes aggregated properties (e.g. count, grouping keys)
  • Validate that:

    • Geometry is extracted correctly from aggregation results
    • No geometry field leaks into properties

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the style view and trace the existing source, layer, popup, and SQL/GeoJSON generation logic. Add regression coverage for the listed response, source, layer, popup, aggregation, and GeoJSON invariants, including deduplication and geometry handling; done means the tests validate the current implementation without database-heavy assertions.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, testing
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.