Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

テストについて #4

Open
rsk0315 opened this issue Sep 30, 2020 · 10 comments
Open

テストについて #4

rsk0315 opened this issue Sep 30, 2020 · 10 comments

Comments

@rsk0315
Copy link
Owner

rsk0315 commented Sep 30, 2020

fn parse_{oj}_{problem_id}(String) -> T の関数(T は問題による)をつくる。
クエリが複数種類あるものは enum で対応する。

その出力を fn solve_{oj}_{problem_id}(T) -> U に投げる。

ジャッジとテストケースを落としてくるやつの雛形は前に書いたのを流用するけど、テストケースの管理はどうしよう。
公開していいのかな(どうせ(まだ)private だけど)

あるいは oj-v.-helper がしてるみたいに、タイムスタンプを残しておいて、重複して試さないようにする? けど fail する限り毎回アクセスすることになるよね

@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 3, 2020

別の private リポジトリにミラーでテストケースを置いて、何らかのトークン経由でそれを参照したり、適宜落としてそっちに push する感じにする?

@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 6, 2020

気づいたけど、#[test] 側がわざわざカスタムジャッジの設定をしようとしてるのはおかしいんだよね

そもそも Fn(String) -> String でやりとりしてるのは面倒だなぁ
入出力を一々やってもうれしくなくて、テストケースは予めパースしてしまって json かなにかにしておきたい

諸々を考えると、testcases.toml で管理するんじゃなくて、Vec<(&str, dyn Box<Fn(String) -> Json>)> みたいなのを置いておくとうれしそうなような

@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 6, 2020

static AOJ_PROBLEM_LIST: Vec<(&str, &Fn(String) -> Json)> = vec![
    "0000", &parse_aoj_0000,
    "DSL_2_B", &parse_aoj_dsl_2_b,
    // ...
];

とかしておいて、?

@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 6, 2020

trait Solver {
    type Input: Deserialize<'static> + Serialize;
    type Output: Eq + Deserialize<'static> + Serialize;
    const TL: Duration;
    const PROBLEM_ID: &str;

    fn parse_input(input: String) -> Input;
    fn parse_output(output: String) -> Output;
    fn solve(input: Input) -> Output;
    fn judge(_input: Input, output: Output, jury: Output) -> Verdict {
        match output == jury {
            true => Ac(1),
            false => Wa(0, None),
        }
    }
}

@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 6, 2020

で、download したときは parse_input を使って JSON にでもしておく。
verify のときは serdeInput / Output に変換して、solve / judge で判定する

@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 6, 2020

面白そうなんだけど、parsejudge は各問題ひとつなのに対して、solve はひとつとは限らないんだよねえ
verifier 側からは

#[test]
fn verify_ds() {
    verify(AojXxxxJudge, aoj_xxxx_solver1::<Ds>);
    verify(AojXxxxJudge, aoj_xxxx_solver2::<Ds>);
    verify(AojYyyyJudge, aoj_yyyy_solver::<Ds>);
}

みたいにできるとよさそ

judge()

fn judge(input: Input, jury: Output, solver: Fn(Input) -> Output) -> Verdict;

であるべき?

結局、download や testset に使う各種情報を Solver に丸投げできるとうれしい。
丸投げするなら名前はそれこそ TestSet みたいな名前にするとかしてもいいか

@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 7, 2020

#21
こんな?
mod じゃなくて crate にするべきだった?

@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 9, 2020

Mo とかみたいな、その解法用のクラスを作って、それがトレイトを実装して、そのトレイトに関する関数や provided methods を確認するみたいなの、どうしよう

@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 9, 2020

AOJ 2444 は foldable deque をかませれば Mo でも解けるけどただただめんどっちゃい、たすけて

@rsk0315 rsk0315 closed this as completed Oct 17, 2020
@rsk0315 rsk0315 reopened this Oct 20, 2020
@rsk0315
Copy link
Owner Author

rsk0315 commented Oct 20, 2020

何らかの verify をする crate なり mod なりで、

pub mod verifies {
    #[doc(inline)]
    pub use something_to_be_verified;
}

みたいに書くのは、どうですか?(ドキュメントにそれへのリンクが貼られてくれるので)
something_to_be_verified から verifier へのリンクは貼られてくれないからまだ不便ではありそう

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant