Organized, flexible testing framework for Rust

Overview

Stainless Build Status

Stainless is a lightweight, flexible, unopinionated testing framework.

Note that stainless currently requires the nightly version of the Rust compiler!

This project is unmaintained

Users are advised to use speculate.rs instead which implements a similar idea.

Installation

Add stainless as a dependency in your Cargo.toml file

[dev-dependencies]
stainless = "*"

Add the following lines to the top of your root module. That file is normally called src/main.rs for executables and src/lib.rs for libraries:

#![feature(plugin)]
#![cfg_attr(test, plugin(stainless))]

This will make stainless available when you run the tests using cargo test. When using stainless only with a library, make sure to run tests using cargo test --lib.

Overview

Stainless exports the describe! syntax extension, which allows you to quickly generate complex testing hierarchies and reduce boilerplate through before_each and after_each.

Stainless currently supports the following types of subblocks:

  • before_each and after_each
  • it, failing, and ignore
  • bench
  • nested describe!

before_each and after_each allow you to group common initialization and teardown for a group of tests into a single block, shortening your tests.

it generates tests which use before_each and after_each. failing does the same, except the generated tests are marked with #[should_panic]. It optionally takes an argument which is matched against the failure message. ignore is equivalent to marking a test with #[ignore] which disables the test by default.

bench allows you to generate benchmarks in the same fashion, though before_each and after_each blocks do not currently affect bench blocks.

Nested describe! blocks allow you to better organize your tests into small units and gives you granular control over where before_each and after_each apply. Of course the before_each and after_each blocks of the wrapping describe! blocks are executed as well.

Together, these 4 types of subblocks give you more flexibility and control than the built in testing infrastructure.

Example

describe! stainless {
    before_each {
        // Start up a test.
        let mut stainless = true;
    }

    it "makes organizing tests easy" {
        // Do the test.
        assert!(stainless);
    }

    after_each {
        // End the test.
        stainless = false;
    }

    bench "something simple" (bencher) {
        bencher.iter(|| 2 * 2)
    }

    describe! nesting {

        before_each {
          let mut inner_stainless = true;
        }

        after_each {
          inner_stainless = false;
        }

        it "makes it simple to categorize tests" {
            // It even generates submodules!
            assert_eq!(2, 2);
        }
    }
}

Expands to (roughly):

mod stainless {
    #[test]
    fn makes_organizing_tests_easy() {
        let mut stainless = true;
        assert!(stainless);
        stainless = false;
    }

    #[bench]
    fn something_simple(bencher: &mut test::Bencher) {
        bencher.iter(|| 2 * 2)
    }

    mod nesting {
        #[test]
        fn makes_it_simple_to_categorize_tests() {
            let mut stainless = true;
            let mut inner_stainless = true;
            assert_eq!(2, 2);
            inner_stainless = false;
            stainless = false;
        }
    }
}

Importing modules

At this point it is not possible to put use statements inside the describe! blocks. To allow usage of data structures from other modules and crates each describe! block comes with a silent pub use super::*; in it. That way everything you pub use in the containing module is available in your tests.

#[cfg(test)]
mod tests {
    pub use std::collections::HashMap;

    describe! stainless {
        it "can use HashMap" {
            let map = HashMap::new();
        }
    }
}

License

MIT. See the LICENSE file for details.

Authors

See Cargo.toml for the full list of authors.

Comments
  • macro

    macro "describe!" is not defined!

    Hey there,

    Sorry for this maybe pretty trivial question but I'm new to Rust and want to start my first project with TDD and therefore your crate right away.

    I have Multirust and rust nightly 1.9.0 and your stainless 1.4.0

    Its compiling fine but running a test (which I tested before using stainless - worked fine) will fail due the undefined macro "describe!". Racer also tells me its not defined on the run.

    Can sb. please give me a hint what I'm missing here?

    greets Charlie

    opened by xetra11 23
  • Improved the README

    Improved the README

    Recently a few people (e.g. @grosser & @xetra11) had issues with stainless mainly due to the lack of documentation. I've tried to clarify the README a bit. See here for how Github would render it.

    • Added note about the fact that the nightly compiler build is required
    • Added instructions on how to integrate stainless
    • Reordered sections (overview before the example)
    • Added before_each & after_each to the nested describe! in the example
    • Clarified the pub use requirement
    opened by ujh 11
  • Allow strings as description for `describe` blocks

    Allow strings as description for `describe` blocks

    It'd be really nice if describe supports long descriptions like it does. We could do the same renaming that it blocks currently do to make the description a valid identifier and use it as the mod name.

    I'm willing to implement this if you think this is a good idea, let me know!

    opened by utkarshkukreti 9
  • Allow to use non snake case for test functions

    Allow to use non snake case for test functions

    As name of test function is generated from description and description can actually have upper case words (for example, referring to structs, enums or problem area’s Terms) it might be pretty annoying to see clobbered output

    opened by vhbit 9
  • Add separate lexical scope for the actual test

    Add separate lexical scope for the actual test

    Assuming the following test:

    before_each {
        let mut interpreter = GTPInterpreter::new(config.clone(), engine);
    }
    
    after_each {
        interpreter.quit();
    }
    
    it "empty string" {
        let response = interpreter.read("");
        assert!(response.is_err());
        assert_that(response.unwrap_err(), is(equal_to("empty command")));
    }
    

    where the read is defined as follows: pub fn read(&mut self, input: &str) -> Result<&str, &str> (not the mut self) I get the following error:

    src/gtp/test.rs:47:9: 47:20 error: cannot borrow `interpreter` as immutable because it is also borrowed as mutable [E0502]
    src/gtp/test.rs:47         interpreter.quit();
                               ^~~~~~~~~~~
    src/gtp/test.rs:37:1: 209:2 note: in this expansion of describe! (defined in src/main.rs)
    src/gtp/test.rs:158:28: 158:39 note: previous borrow of `interpreter` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `interpreter` until the borrow ends
    src/gtp/test.rs:158             let response = interpreter.read("list_commands\n");
                                                   ^~~~~~~~~~~
    

    Obviously this is easy to fix by wrapping the contents of it in another pair of curly braces, but wouldn't it be nice if stainless did that for you? I mean, is there a downside to always doing it like this?

    BTW, I'd be willing to have a look at this myself.

    opened by ujh 8
  • Add support for nested hooks.

    Add support for nested hooks.

    I've marked this as WIP because for some reason before_each seems to be nesting fine, but after_each aren't nesting. The assertion in tests/nested_hooks.rs line 11 should fail but isn't being executed at all. I'm probably making some obvious mistake here.. any ideas?

    opened by utkarshkukreti 8
  • after_each may be executed before the test (if it contains only a statement that doesn't end with a semicolon)

    after_each may be executed before the test (if it contains only a statement that doesn't end with a semicolon)

    Hello,

    First and foremost, thank you for this framework! It really helps in writing readable tests :smiley:

    I came across an edge case, today: if you don't have statements that end with a semicolon, the generated code doesn't get ordered properly. For example:

    #![feature(const_fn, plugin)]
    #![plugin(stainless)]
    
    describe! thread {
        before_each {
            let mut after_each_done = false;
        }
    
        it "should be executed in the middle" {
            // I concede, tests shouldn't have contain ifs. But in this case, it helps showing 
            // the failure, without looking at the expanded macros.
            if !after_each_done {
                assert!(true);
            } else {
                panic!();
            }
        }
    
        after_each {
            after_each_done = true;
        }
    }
    

    Here's a part of the code when macros are expanded:

        pub fn should_be_executed_in_the_middle() 
         {
            let mut after_each_done = false;
    
            after_each_done = true;
            if !after_each_done {
            // test code below
    
    opened by JohanLorenzo 7
  • Fails to compile under rust 1.8.0 nightly?

    Fails to compile under rust 1.8.0 nightly?

    After updating my multirust to 1.8.0 nightly it seems stainless no longer compiles. Getting the error

    cargo test                                                                                                                                                                                                                                                                                                     
       Compiling stainless v0.1.3
    .multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/stainless-0.1.3/src/parse.rs:40:49: 40:53 error: no method named `ok` found for type `syntax::parse::token::Token` in the current scope
    .multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/stainless-0.1.3/src/parse.rs:40         let name = match (parser.bump_and_get().ok().unwrap(),parser.parse_ident().ok().unwrap(), parser.bump_and_get().ok().unwrap()) {                                                                                                                                                                     
    .multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/stainless-0.1.3/src/parse.rs:40:122: 40:126 error: no method named `ok` found for type `syntax::parse::token::Token` in the current scope.multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/stainless0.1.3/src/parse.rs:40         let name = match (parser.bump_and_get().ok().unwrap(), parser.parse_ident().ok().unwrap(), parser.bump_and_get().ok().unwrap()) {                                                                                                                                                                                                                                                     
    .multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/stainless-0.1.3/src/parse.rs:165:38: 165:42 error: no method named `ok` found for type `syntax::parse::token::Token` in the current scope.multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/stainless0.1.3/src/parse.rs:165     let real = parser.bump_and_get().ok().unwrap();
    

    Not sure if you guys are aware of this, or if anyone else is experiencing this. Is there anything I can do in the meantime to fix this?

    opened by angrygoats 7
  • Add MIT license and license headers

    Add MIT license and license headers

    I went through the whole commit history and added everyone who contributed even a single line to the license headers. Everyone is now also in the cargo file. The ordering of the names in the headers is somewhat random, I just added the name whenever I found it. That is apart from @reem. :) He's first whenever he contributed in a given name. And in the cargo file the names are sorted alphabetically. Again apart from Jonathan.

    opened by ujh 5
  • Compiler error from Stainless library on OSX 10.12.6

    Compiler error from Stainless library on OSX 10.12.6

    
    Compiling stainless v0.1.11
    error[E0063]: missing field `tokens` in initializer of `syntax::ast::Item`
       --> /Users/jimdandy/.cargo/registry/src/github.com-1ecc6299db9ec823/stainless-0.1.11/src/generate.rs:113:11
        |
    113 |         P(ast::Item {
        |           ^^^^^^^^^ missing `tokens`
    
    error[E0063]: missing field `tokens` in initializer of `syntax::ast::Item`
       --> /Users/jimdandy/.cargo/registry/src/github.com-1ecc6299db9ec823/stainless-0.1.11/src/generate.rs:149:11
        |
    149 |         P(ast::Item {
        |           ^^^^^^^^^ missing `tokens`
    
    error: aborting due to 2 previous errors
    
    error: Could not compile `stainless`.
    
    opened by vanthemilton 4
  • Before and after subblocks don't work

    Before and after subblocks don't work

    The before and after subblocks seem to doesn't work. They are parsed but never call during the execution.

    #![feature(plugin)]
    #![plugin(stainless)]
    
    describe! addition {
        before {
            println!("In before");
        }
    
        before_each {
            println!("in before each");
            let x = 5;
            let y = 6;
        }
    
        it "should add 5 and 6 together" {
            assert_eq!(x + y, 11);
        }
    
        after_each {
            println!("in after each");
        }
    
        after {
            println!("In after");
        }
    }
    
    

    That give me this result :

    cargo test -- --nocapture
    .....
    running 1 test
    in before each
    in after each
    test addition::should_add_5_and_6_together ... ok
    
    $ rustc --version
    rustc 1.17.0-nightly (c0b7112ba 2017-03-02)
    
    [dependencies]
    stainless = "0.1.10"
    
    
    bug 
    opened by NotBad4U 4
  • Broken with nightly as of 2018-02-28

    Broken with nightly as of 2018-02-28

    I currently get this on git master and nightly of 2018-02-28:

    error[E0599]: no associated item named `Inherited` found for type `syntax::codemap::Spanned<syntax::ast::VisibilityKind>` in the current scope
       --> /home/svenstaro/.cargo/git/checkouts/stainless-0b08235192b57707/f89f435/src/generate.rs:135:18
        |
    135 |             vis: ast::Visibility::Inherited,
        |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ associated item not found in `syntax::codemap::Spanned<syntax::ast::VisibilityKind>`
    
    error[E0599]: no associated item named `Inherited` found for type `syntax::codemap::Spanned<syntax::ast::VisibilityKind>` in the current scope
       --> /home/svenstaro/.cargo/git/checkouts/stainless-0b08235192b57707/f89f435/src/generate.rs:179:18
        |
    179 |             vis: ast::Visibility::Inherited,
        |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ associated item not found in `syntax::codemap::Spanned<syntax::ast::VisibilityKind>`
    
    error[E0599]: no associated item named `Public` found for type `syntax::codemap::Spanned<syntax::ast::VisibilityKind>` in the current scope
       --> /home/svenstaro/.cargo/git/checkouts/stainless-0b08235192b57707/f89f435/src/generate.rs:228:47
        |
    228 |         let super_glob = cx.item_use_glob(sp, ast::Visibility::Public, vec![cx.ident_of("super")]);
        |                                               ^^^^^^^^^^^^^^^^^^^^^^^ associated item not found in `syntax::codemap::Spanned<syntax::ast::VisibilityKind>`
    
    opened by svenstaro 12
  • Panic when compiling a describe block with a string instead of identifier

    Panic when compiling a describe block with a string instead of identifier

    I have the following src/main.rs:

    #![feature(plugin)]
    #![cfg_attr(test, plugin(stainless))]
    
    describe! stainless {
        describe! "add" {
            it "works" {}
        }
    }
    

    When I run cargo test, I get:

    error: internal compiler error: unexpected panic
    
    note: the compiler unexpectedly panicked. this is a bug.
    
    note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
    
    note: rustc 1.24.0-nightly (4a7c072fa 2017-12-25) running on x86_64-pc-windows-msvc
    
    note: run with `RUST_BACKTRACE=1` for a backtrace
    
    thread 'rustc' panicked at 'Diagnostic { level: Fatal, message: [("Failed to parse the name of the describe block, got err: Diagnostic { level: Fatal, message: [(\"expected identifier, found `\\\"add\\\"`\", NoStyle)], code: None, span: MultiSpan { primary_spans: [Span { lo: BytePos(95), hi: BytePos(100), ctxt: #0 }], span_labels: [] }, children: [], suggestions: [] }", NoStyle)], code: None, span: MultiSpan { primary_spans: [Span { lo: BytePos(95), hi: BytePos(100), ctxt: #0 }], span_labels: [] }, children: [], suggestions: [] }', C:\Users\Per\.cargo\registry\src\github.com-1ecc6299db9ec823\stainless-0.1.12\src\parse.rs:109:24
    stack backtrace:
       0: std::sync::mpsc::sync::Queue::dequeue
       1: std::panicking::Location::column
       2: std::panicking::Location::column
       3: std::panicking::rust_panic_with_hook
       4: std::panicking::begin_panic_fmt
       5: std::panicking::begin_panic_fmt
       6: stainless::parse::{{impl}}::parse
                 at C:\Users\Per\.cargo\registry\src\github.com-1ecc6299db9ec823\stainless-0.1.12\src\parse.rs:109
       7: stainless::parse::{{impl}}::parse
                 at C:\Users\Per\.cargo\registry\src\github.com-1ecc6299db9ec823\stainless-0.1.12\src\parse.rs:180
       8: stainless::describe::describe
                 at C:\Users\Per\.cargo\registry\src\github.com-1ecc6299db9ec823\stainless-0.1.12\src\describe.rs:66
       9: core::ops::function::Fn::call<fn(mut syntax::ext::base::ExtCtxt*, syntax_pos::span_encoding::Span, syntax_pos::symbol::Ident, alloc::vec::Vec<syntax::tokenstream::TokenTree>) -> alloc::boxed::Box<MacResult>,(mut syntax::ext::base::ExtCtxt*, syntax_pos::span_encoding::Span, syntax_pos::symbol::Ident, alloc::vec::Vec<syntax::tokenstream::TokenTree>)>
                 at C:\projects\rust\src\libcore\ops\function.rs:73
      10: syntax::ext::base::{{impl}}::expand<fn(mut syntax::ext::base::ExtCtxt*, syntax_pos::span_encoding::Span, syntax_pos::symbol::Ident, alloc::vec::Vec<syntax::tokenstream::TokenTree>) -> alloc::boxed::Box<MacResult>>
                 at C:\projects\rust\src\libsyntax\ext\base.rs:261
      11: syntax::ext::expand::MacroExpander::expand_crate
      12: syntax::ext::expand::MacroExpander::expand_crate
      13: syntax::ext::expand::MacroExpander::expand_crate
      14: rustc_driver::driver::count_nodes
      15: rustc_driver::driver::count_nodes
      16: rustc_driver::driver::compile_input
      17: rustc_driver::run_compiler
      18: <rustc_driver::pretty::UserIdentifiedItem as core::fmt::Debug>::fmt
      19: _rust_maybe_catch_panic
      20: rustc_driver::profile::dump
      21: std::sync::mpsc::sync::Queue::dequeue
      22: std::sys::windows::thread::Thread::new
      23: BaseThreadInitThunk
    
    

    Note that this only happens for a nested describe!. If I change the code to describe! "stainless" {, I get a proper error message:

    error: expected open delimiter
     --> src\main.rs:4:11
      |
    4 | describe! "stainless" {
      |           ^^^^^^^^^^^
    
    
    opened by provegard 6
  • Certain kinds of errors inside `before_each` cause the compiler to panic

    Certain kinds of errors inside `before_each` cause the compiler to panic

    Stainless version: 0.1.11 rustc version: 1.19.0-nightly (75b056812 2017-05-15)

    A minimal test case follows. I put the code in src/test.rs and src/main.rs only contains configuration needed for stainless, and a mod test; declaration.

    describe! my_module {
        before_each {
            let a = (0..2).map(|x| error_token)
        }
    }
    

    (Note the missing semicolon; without it, everything works fine.)

    After running cargo test, I'm getting the following output:

    error: internal compiler error: Error constructed but not emitted
    
    error: internal compiler error: unexpected panic
    
    note: the compiler unexpectedly panicked. this is a bug.
    
    note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
    
    note: run with `RUST_BACKTRACE=1` for a backtrace
    
    thread 'rustc' panicked at 'explicit panic', /checkout/src/librustc_errors/diagnostic_builder.rs:204
    note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
    stack backtrace:
       0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
                 at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
       1: std::sys_common::backtrace::_print
                 at /checkout/src/libstd/sys_common/backtrace.rs:71
       2: std::panicking::default_hook::{{closure}}
                 at /checkout/src/libstd/sys_common/backtrace.rs:60
                 at /checkout/src/libstd/panicking.rs:355
       3: std::panicking::default_hook
                 at /checkout/src/libstd/panicking.rs:365
       4: std::panicking::rust_panic_with_hook
                 at /checkout/src/libstd/panicking.rs:549
       5: std::panicking::begin_panic
       6: <rustc_errors::diagnostic_builder::DiagnosticBuilder<'a> as core::ops::Drop>::drop
       7: core::ptr::drop_in_place
                 at /checkout/src/libcore/ptr.rs:60
       8: core::ptr::drop_in_place
                 at /checkout/src/libcore/ptr.rs:60
       9: <core::result::Result<T, E>>::ok
                 at /checkout/src/libcore/result.rs:341
      10: <stainless::describe::DescribeState as stainless::parse::Parse<(syntax_pos::Span, &'a mut syntax::ext::base::ExtCtxt<'b>, core::option::Option<syntax_pos::symbol::Ident>)>>::parse
                 at /home/geomaster/.cargo/registry/src/github.com-1ecc6299db9ec823/stainless-0.1.11/src/parse.rs:143
      11: stainless::describe::describe
                 at /home/geomaster/.cargo/registry/src/github.com-1ecc6299db9ec823/stainless-0.1.11/src/describe.rs:68
      12: core::ops::Fn::call
                 at /checkout/src/libcore/ops.rs:2567
      13: <F as syntax::ext::base::IdentMacroExpander>::expand
                 at /checkout/src/libsyntax/ext/base.rs:260
      14: syntax::ext::expand::MacroExpander::expand_invoc
      15: syntax::ext::expand::MacroExpander::expand
      16: syntax::ext::expand::MacroExpander::expand_crate
      17: rustc_driver::driver::phase_2_configure_and_expand::{{closure}}
      18: rustc_driver::driver::phase_2_configure_and_expand
      19: rustc_driver::driver::compile_input
      20: rustc_driver::run_compiler
    

    I'll be happy to provide any further information, if needed.

    opened by geomaster 0
  • Add more friendly error messages (WIP)

    Add more friendly error messages (WIP)

    So I learned a bit playing with this crate seeing if I could fix issue #49.

    Here's what I got screen shot 2017-02-18 at 1 00 16 am

    This PR right now just demonstrates a nicer way to surface the error in one place. I can apply this same way of surfacing the error across the rest of the crate where we currently have panics.

    The reason it is still panicing is because Parse::parse() still requires a return value of self, and since parse_block failed to return an syntax::ast::Block, I don't have a value to use for Test::block.

    @reem I was hoping to get your opinion on what your preferred way to apply this change would be. This is my first time working with syntax extensions and I don't have much experience writing syntax parsers in general.

    Options I see (but there certainly could be some I'm overlooking):

    • Make Test::block an option type, make it none when parse_block() fails. Although I'm not sure how Generate::generate should behave when block is None
    • Still panic anytime a parse fails, but add this friendlier way of displaying the error beforehand. This is really ugly and hacky but easiest to implement and still gives the user the info they need to locate the issue.
    • Make Parse::parse return an Option. Not really sure about the implications of this one. Again, parsing and syntax extensions is really not my area of expertise.

    I think I can implement any of the 3 myself, but would definitely appreciate a bit of insight beforehand.

    opened by echochamber 7
Owner
Jonathan Reem
Jonathan Reem
CosmWasm multi-contract testing framework

Multi Test: Test helpers for multi-contract interactions Warning: Alpha Software Designed for internal use only. This is used for testing cw-plus cont

CosmWasm 7 Dec 6, 2022
Flexible Rust implementation of the MuSig2 multisignature protocol, compatible with Bitcoin.

MuSig2 This crate provides a flexible rust implementation of MuSig2, an optimized digital signature aggregation protocol, on the secp256k1 elliptic cu

null 4 Oct 31, 2023
Flexible secp256k1 curve math library.

secp A flexible and secure secp256k1 elliptic curve math library, with constant-time support, and superb ergonomics. secp takes full advantage of Rust

null 7 Nov 1, 2023
Local blockchain for Free TON DApp development and testing.

TON OS Startup Edition Local blockchain for Free TON DApp development and testing. Have a question? Get quick help in our channel: TON OS Startup Edit

TON Labs 35 Jan 2, 2023
An Ethereum 2.0 Emulator for Local Testing of Eth2 Applications

Mousse is an Ethereum 2.0 emulator for local testing of Eth2 applications (mainly Rollups). HTTP Server The REST API definition can be found in the ht

Mousse 46 Sep 10, 2022
Testing a smart contract on the Solana blockchain

Environment Setup Install Rust from https://rustup.rs/ Install Solana from https://docs.solana.com/cli/install-solana-cli-tools#use-solanas-install-to

Maurice 1 Oct 25, 2021
Automated security testing for open source libraries and applications.

autovet continuously searches for security breaches in open source libraries and applications. Recently processed packages package version channel las

null 5 Aug 23, 2022
Parser and test runner for testing compatable common Ethereum full node tests against Polygon Zero's EVM.

EVM Test Parses and runs compatible common Ethereum tests from ethereum/tests against Polygon Zero's EVM. Note: This repo is currently very early in d

Mir Protocol 3 Nov 4, 2022
Kinda functional block engine for testing bundles on jito-solana locally

Half Baked Block Engine About This is a half-baked block engine. It can be used for testing bundles running through jito-solana. Shortcomings The bare

null 8 Nov 16, 2022
FRI low-degree-testing & polynomial commitment scheme

fri-commitment FRI low degree testing & FRI polynomial commitment using [VP19]'s trick. Implementation using arkworks libraries. Note: done in my free

null 10 Mar 31, 2023
Snapshot testing tool for Nix based on haumea [maintainer=@figsoda]

namaka Snapshot testing tool for Nix based on haumea nix shell github:nix-community/namaka namaka check # run checks namaka review # review pending sn

Nix community projects 30 Apr 17, 2023
A specialized blockchain for testing use cases with the FRAME NFTs Pallet.

Substrate NFTs Node The Substrate NFTs node is a specialized blockchain for testing use cases with the FRAME NFTs Pallet. ?? The purpose of this node

Sacha Lansky 4 May 25, 2023
Glommio Messaging Framework (GMF) is a high-performance RPC system designed to work with the Glommio framework.

Glommio Messaging Framework (GMF) The GMF library is a powerful and innovative framework developed for facilitating Remote Procedure Calls (RPCs) in R

Mohsen Zainalpour 29 Jun 13, 2023
A simple frontend web app in the seed.rs Rust framework.

Seed Quickstart Basic Rust-only template for your new Seed app. 1. Create a new project You can use cargo generate to use this template. $ cargo gener

null 0 Dec 24, 2021
Implementation of Proof of Existence consensus using Substrate Framework, Frame, Pallets, RUST

Substrate Node Template A fresh FRAME-based Substrate node, ready for hacking ?? Getting Started Follow the steps below to get started with the Node T

Vijayendra Gaur 1 Jun 8, 2022
A network application framework for Rust

This crate is deprecated! This crate is deprecated without an immediate replacement. Discussion about a successor can be found in tokio-rs/tokio#118.

Tokio 700 Dec 12, 2022
Rust-Rocket framework template Demo

rocketapp Rust-Rocket framework template Demo dependencies are defined in Cargo.toml Clone as: git clone https://github.com/srikantgdev/rocketapp [op

Srikant Gudi 3 Oct 27, 2022
Rustycan - UI framework for Rust with focus on developer ergonomics for retained or immediate-like mode

Rustycan is a powerful UI framework for Rust, designed to make it easier than ever to create UIs and update existing UIs for games or apps.

Nokola 3 Jan 3, 2023
MLIR Rust multi-level compiler framework

MLIR-RS Multi-Level Intermediate Representation framework for Rust. What Modern programming language design is moving towards multi-level lowering to

Conrad Ludgate 16 May 29, 2023