Save test cases in files

qryxip commented 4 years ago

ファイルに保存して閲覧、編集できたほうが便利だと思うので。方針としては以下の2つがあります。

ディレクトリにテキストを入れる

tests/in/test1.txtとtests/out/test1.txt、あるいはtests/test1.inとtests/test2.inをペアにするような保存形式です。

oj(とそれに依存するatcoder-cli等のツール)をはじめとしたほぼすべての競プロツールがこれのはずです。

Pros

我々の実装が非常に楽
その場のシェルスクリプトで簡単にテストケースを追加できる
外部から読みやすい
MiB級のサイズのデータに追加の対応が要らない

Cons

一覧するのが面倒
直に書き込むのにファイルを2つ開く必要がある

JSONやYAMLで管理

competitive-companionとかがこれです。あと私が作ったのも。

一応、大きいデータに対応するため一部をテキストファイルに替えることができます。

私のツールだとこんなのです。

---
type: batch       # "batch", "interactive", or "unsubmittable"
timelimit: 2000ms # optional
match: exact      # "any", "exact", or "float"

cases:
  - name: Sample 1
    in: |
      1
      2 3
      test
    out: |
      6 test
  - name: Sample 2
    in: |
      72
      128 256
      myonmyon
    out: |
      456 myonmyon
  # "name" and "out" are optional
  - in: |
      1000
      1000 1000
      oooooooooooooo

Pros

上記のConsの逆
コンテスト開始時にRustのソースファイルと共にエディタで開くといったことが可能

Cons

上記のProsの逆

tatsuya0619 commented 4 years ago

質問させてください。入力と出力を2つのファイルに分けるのではなく、同一ファイル内で空行で分けた方が楽だと思ったのですが、何か理由があるんですか?(Atcoderでは空行を含んだ入出力が存在するとか?)

qryxip commented 4 years ago

よくわからないですね... 強いて言うならcat "$input_file" | "$solution"のようなことが楽になるとかDropboxで公開されているフルのテストケース(zip)がそのまま突っ込めるとかですかね(ojはDropboxからのダウンロードはできない)。テストケースをエディタで直接開くことをあまり想定していないのかも。

空行は...今まで見たことがないですね。「入力は与えられない」という問題とかLFじゃなくCRLFとかEOLが無い(どの問題だったか忘れた)というのはありますが。

(ところでDropboxからツールでダウンロードするのは実際つらいです。私の場合はAPIを使ったのですが、何故かtokenが要求されるのでclient_secretを公開し、zipではダウンロードできないのでテキストファイルを一つ一つ引っ張るはめになりました。)

dropbox

tatsuya0619 commented 4 years ago

ツールからしか使わない想定はありえそうですね。ありがとうございました!

tanakh / cargo-atcoder