{"id":15070059,"url":"https://github.com/ruc-course-development/contest","last_synced_at":"2025-12-24T01:47:57.163Z","repository":{"id":47067455,"uuid":"128838497","full_name":"ruc-course-development/contest","owner":"ruc-course-development","description":"A Console Application Tester","archived":false,"fork":false,"pushed_at":"2024-09-25T13:46:15.000Z","size":140,"stargazers_count":4,"open_issues_count":4,"forks_count":2,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-03-24T14:51:20.579Z","etag":null,"topics":["console","python","python-3","python3","testing","testing-tools","yaml"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ruc-course-development.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-04-09T21:57:13.000Z","updated_at":"2024-09-25T13:45:10.000Z","dependencies_parsed_at":"2024-11-17T18:25:46.638Z","dependency_job_id":"ce5b36ed-0e08-4269-a651-3057f0ebcda0","html_url":"https://github.com/ruc-course-development/contest","commit_stats":{"total_commits":149,"total_committers":4,"mean_commits":37.25,"dds":0.09395973154362414,"last_synced_commit":"1b6372d8bf00ae975ab095e1adf0d963f2f81651"},"previous_names":["lnk2past/contest"],"tags_count":21,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ruc-course-development%2Fcontest","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ruc-course-development%2Fcontest/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ruc-course-development%2Fcontest/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ruc-course-development%2Fcontest/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ruc-course-development","download_url":"https://codeload.github.com/ruc-course-development/contest/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248261413,"owners_count":21074222,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["console","python","python-3","python3","testing","testing-tools","yaml"],"created_at":"2024-09-25T01:46:47.500Z","updated_at":"2025-12-24T01:47:52.137Z","avatar_url":"https://github.com/ruc-course-development.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# contest\n\n[![Build Status](https://github.com/Lnk2past/contest/workflows/Build/badge.svg)](https://github.com/Lnk2past/contest/actions)\n[![PyPI version shields.io](https://img.shields.io/pypi/v/contest.svg)](https://pypi.python.org/pypi/contest/)\n![Python](https://img.shields.io/badge/python-3.9%20%7C%203.10%20%7C%203.11%20%7C%203.12-red)\n\nA `CON`sole application `TEST`er. THIS WHOLE REPO NEEDS AN OVERHAUL!\n\n## Introduction\n\n`contest` is a testing application that exercises a program with configured input and then checks the output with some expected content. Simply: `contest` validates executable output given specific inputs.\n\n### Motivation\n\nI wrote this for a class that I teach to help with grading. Given the configuration driven nature of it (how else should a testing framework/tool work?) `contest` lets me define multiple test cases for particular programs (assignments) so that not only is grading easier for me, but I can integrate assignments into a grading pipeline so that I can do as little work as possible and my students can get immediate feedback on submissions. Assignments here are usually single-file programs that are not necessarily unit-testable without adding in boilerplate and nonstandard language features. Letting students build normal programs and then verify their behavior is the goal.\n\n## Installation\n\n```shell\npip install contest\n```\n\nYou may install from this repo, clone and simply:\n\n```shell\npython setup.py install\n```\n\n## How It Works\n\n### Overview\n\nYAML is the preferred choice of input for `contest` for a few reasons, but most notably for its easy to follow syntax and allowance of multiline strings (sorry JSON). `contest` consumes an input file that specifies at least one executable and then whatever additional information is provided. Check out the test skeleton below to see what can be specified; the main ones though are the input and output streams `stdout`, `stderr`, and `stderr` as well and CLI inputs `argv`. You can specify newly generated files that you expect to be created and even go further and specify custom tests (as `Python` files) that cover the things simple I/O comparisons do not. Lastly, you may also specify environment variables to be set during the execution; and you may also scrub the environment before adding custom keys. Note that scrubbing the environment may prevent your executable from running altogether! For now you are better off allowing your current environment to persist and simply overwrite what needs to be set. Environment variables specified within a test-case take precedence over what is in your current environment.\n\n#### Test Skeleton\n\n```yaml\nexecutable:                 # !!str, name of the executable to use for all tests\ntest-cases:                 # !!seq, list of all test cases\n    - name:                 # !!str, name of the test\n      scrub-env:            # !!bool, flag to remove the current environment\n      env:                  # !!map, environment variables to set\n      resources:            # !!seq, list of resources to copy to the test directory, need to provide a src and dst\n      executable:           # !!str, name of the executable to use for this test case only\n      argv:                 # !!seq, list of arguments to pass to the executable\n      stdin:                # !!str || !!seq inputs to standard input stream\n        # * see below\n      returncode:           # !!int, expected return code\n      stdout:               # !!str || !!seq || !!map, expected output in standard output stream\n        # ** see below\n      stderr:               # !!str || !!seq || !!map, expected output in standard error stream\n        # ** see below\n      ofstreams:            # !!seq, list of files to compare\n            # *** see below\n      extra-tests:          # !!seq, list of additional modules to load for additional tests\n```\n\n\\* The stdin field can either be a block of text (one entry to stdin per line) or can be provided as a list.\n\n\\*\\* These fields can either be text blocks, lists, or dictionaries. As a text block or list, it should be the expected output as is. As dictionaries the following fields are allowed:\n\n```yaml\ntext:         # !!str, expected output as a string\nfile:         # !!str, file containing the text to compare against. useful for keeping the size of these files small if desired\nempty:        # !!bool, flag to explicitly check if a stream is empty or nonempty. all other checks are ignored\nstart:        # !!int, 0-indexed line offset to specify where to start comparisons\ncount:        # !!int, number of lines to compare\n```\n\nAll fields are optional, so long as whatever is (or is not) specified makes sense.\n\n\\*\\*\\* These fields are dictionaries and in addition to the fields specified above, the following fields are allowed:\n\n```yaml\ntest-file:    # !!str, path to file generated, absolute or relative to the executable\nexists:       # !!bool, flag to check if the file exists. all other checks are ignored\nbinary:       # !!bool, flag to indicate the file is binary\n```\n\nOther than `test-file`, each field is optional, so long as whatever is (or is not) specified makes sense.\n\n## Basic Usage\n\nGiven some configuration you can run `contest` using the following:\n\n```shell\ncontest \u003cpath to configuration file\u003e\n```\n\nThis will parse the configuration and run the specified test case(s). In the configuration file each test case is defined under the `test-cases` node in the recipe; simply add a new section as desired. You will just need to make sure each test is named uniquely. Here is an example of a test recipe (taken from `examples/native_console_app`):\n\n```yaml\nexecutable: hello_world.exe\ntest-cases:\n  - name: standard\n    stdin: Lnk2past\n    stdout: |\n      Hello! What is your name?\n      Welcome to the world, Lnk2past!\n```\n\nLet us break down what this is specifying:\n\n1. The name of the `executable` to run is\n\n    ```text\n    hello_world.exe\n    ```\n\n2. We have a single test-case named\n\n    ```text\n    standard\n    ```\n\n3. We define the input to `stdin`, which is a single entry:\n\n    ```text\n    Lnk2past\n    ```\n\n4. We define the output to `stdout`, which is:\n\n    ```text\n    Hello! What is your name?\n    Welcome to the world, Lnk2past!\n    ```\n\nThis is really the equivalent of the following in some shell environment:\n\n```shell\n~/project\u003e ./hello_world.exe\nHello! What is your name?\nLnk2past\nWelcome to the world, Lnk2past!\n```\n\nThis means that when running the executable `hello_world.exe` we can expect the input in step 3 to yield the output in step 4. `contest` does this comparison for you! This allows you to write tests that would reflect actual use cases of your executable. Add as many tests as you like to cover various pathways through your program and to cover the various errors your program may encounter.\n\nCheck out the other examples under the `examples` directory.\n\n### Test Directories\n\n`contest` will run each test-case in a separate directory, and will create those directories in the same directory containing the test recipe. This ensures minimal conflict between test cases. For example, if your test recipe contains test cases \"foo\" and \"bar\" and is located in \"C:\\Users\\Lnk2past\\MyProject\", then you can expect the following directory structure:\n\n```text\nC:\\Users\\Lnk2past\\MyProject\\\n|---src\\...\n|---include\\...\n|---contest_recipe.yaml\n|---test_output\\\n    |---foo\\...\n    |---bar\\...\n```\n\nEven if your test-case produces no output on disk, the test-output directory will be created.\n\n### Filtering Tests\n\nYou can filter your test-recipes to only run a select few. This may be useful during debugging to only run your new test without needing to run the entire test recipe. You can do this via the `--filter` option. This expects some `regular expression` to filter on. e.g. we can test only those tests that are marked with a specific keyword in their names, say \"tracking\", by doing the following:\n\n```shell\ncontest test_recipe.yaml --filter \"tracking\"\n```\n\nLikewise, you can exclude specific tests in order if they are problematic or if you are focusing on other tests. simply use the `--exclude-filters` or `--exclude` for short. So long as you know `regex` you can do whatever you like for filtering your tests!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fruc-course-development%2Fcontest","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fruc-course-development%2Fcontest","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fruc-course-development%2Fcontest/lists"}