Unit Testing

[utterances-bot]

This is a general purpose comment thread for the “Unit Testing” post.

[NickTaylor-]

array-init should be set to 0.0.3 in your Cargo.lock, otherwise it will cause this error:

error[E0277]: the trait bound `[volatile::Volatile<vga_buffer::ScreenChar>; 80]: array_init::IsArray` is not satisfied
   --> src/vga_buffer.rs:163:35
    |
163 |             chars: array_init(|_| array_init(|_| Volatile::new(empty_char())))
    |                                   ^^^^^^^^^^ the trait `array_init::IsArray` is not implemented for `[volatile::Volatile<vga_buffer::ScreenChar>; 80]`
    |
    = help: the following implementations were found:
              <[T; 28] as array_init::IsArray>
              <[T; 24] as array_init::IsArray>
              <[T; 53] as array_init::IsArray>
              <[T; 13] as array_init::IsArray>
            and 61 others
    = note: required by `array_init::array_init`

In the code on GitHub it is the correct version, however this document has it set to 0.0.2.

[phil-opp]

Thanks for reporting! Fixed in 0aaeb52.

[lilyball]

The initial construct_buffer() definition has two syntax errors. It's missing a semicolon after the let empty_char = …, and the color_code: field on this same item has a bad value.

[lilyball]

Since ScreenChar is Copy it seems unnecessary to define a separate fn empty_char(), you could just use a let empty_char = ScreenChar { … } like you did in the first version of construct_buffer() and capture it in the closures.

[lilyball]

Oooh I see you're using empty_char() again later.

[orpheeantoniadis]

Hello, i'm writing an os in rust for a school project and all your work is really helpful, thank you. I started to look for unit tests but from the os environnement and not from the host machine like you show here. Unfortunately you will talk about that in the next post and i cannot find any informations on the internet. Can you give me some hints so I dont have to wait for the next post ?

[robert-w-gries]

@orpheeantoniadis Look into utest. It wasn't pretty but I managed to get a trivial unit test working. See the commit here.

Note that my kernel was based off of the first edition series of Phil's kernel, so the kernel was built as a static library instead of a binary. I believe it will be easier to integrate utest if you're building your kernel as a binary with Phil's bootimage tool.

[orpheeantoniadis]

@robert-w-gries Thanks for your answer, I will look what you send. I am not following Phil's blog because we have a system programming course about that in my school but my kernel looks more like first edition but in 32-bit mode.

[memoryruins]

As always, great post!

For anyone interested, proptest recently added no_std and alloc support proptest-rs/proptest#48 and theres a rust-lang rfc for custom test frameworks rust-lang/rfcs#2318

[phil-opp]

@kballard

The initial construct_buffer() definition has two syntax errors. It's missing a semicolon after the let empty_char = …, and the color_code: field on this same item has a bad value.

Thanks, fixed in cb1fa39.

Since ScreenChar is Copy it seems unnecessary to define a separate fn empty_char()

The method is not strictly necessary, it just makes the following code snippets less verbose (as you noticed, empty_char is used in again later).

[phil-opp]

@orpheeantoniadis Thanks!

Can you give me some hints so I dont have to wait for the next post ?

I don't have worked out the details yet, but my plan is to do something much simpler than utest:

• Split the project in a library (src/lib.rs) and a binary (src/main.rs).
• Create additional integration test executables in src/bin.
  • These test executables are executed in QEMU and use serial I/O to write to host stdout.
  • Each executable passes . (test passed) or F (test failed) to the host and then shuts down the machine.
• Our custom test runner crate will compile and run all extra all executables and verify that they succeed.

So this won't be a way of running unit tests in the target environment, but rather a way of writing a few high-level integration tests to verify that the components work correctly with the hardware (e.g. that adding a page table entry makes the corresponding page accessible).

[phil-opp]

@memoryruins Thanks! Never heard of proptest, but it looks really cool! Maybe I'll update this post to mention it. The custom test framework RFC might be useful for creating integration tests in the next post, depending on how it will be implemented.

[4e554c4c]

In ESALP we're going to output the test-anything-protocol to the serial bus to do integration testing.
Creating a test environment on the host machine and doing unit testing is a good idea too (it certainly would have caught a few bugs I've had). :p

[phil-opp]

@4e554c4c

In ESALP we're going to output the test-anything-protocol to the serial bus to do integration testing.

Cool! The test-anything-protocal seems really fitting. Do you use some tool to verify the test output?

[ojii]

In https://os.phil-opp.com/unit-testing/#unit-tests-for the #[cfg(not(test))] should be added to pub fn panic(info: &PanicInfo) -> !. There is no pub extern "C" fn rust_begin_panic

[dodikk]

For some reason use std::boxed::Box; requires a vga_buffer:: for me.
Not sure what I've screwed up (no way that such nice tutorial contains non-compiling code).

P.S. I'm trying to have VGA related code (including tests) in a separate file.

// this compiles
use vga_buffer::std::boxed::Box; 

// this does not
use ::std::boxed::Box; 

[dodikk]

@phil-opp , could you please explain how to build a test suite if the target embedded platform has a different byte order?

For example, the embedded circuit has big endian while workstation which is used for coding has little endian.

I understand that "safe Rust" code is not supposed to have such problems... But "bare metal" will have some. And doesn't the statement"unsafe" needs the more tests make sense?

[dodikk]

@phil-opp , could you please explain how to build a test suite if the target embedded platform has a different byte order?

I guess, that might be covered by the "integration tests" article. https://os.phil-opp.com/integration-tests/

Please consider extending the What's nest? section with the given example.
Thanks.

[phil-opp]

could you please explain how the BUFFER_WIDTH and BUFFER_HEIGHT are omitted in the new call? As far as I can see, array_init() is capable of picking them up from the declaration of struct Buffer via some sizeoff() operation.

The width and height are deduced by type inference. The return type of array_init is generic (i.e. it can return arrays of different types and sizes), but the only type that fits the requirement of the chars field is an array of BUFFER_WIDTH * BUFFER_HEIGHT screen characters. So the Rust compiler deduces the return type of array_init to the correct sizes.

[phil-opp]

For some reason use std::boxed::Box; requires a vga_buffer:: for me.

That's really strange. Maybe you accidentally put the extern crate std definition inside your VGA buffer module? (extern crate declarations should be always at the main.rs/lib.rs)

[phil-opp]

could you please explain how to build a test suite if the target embedded platform has a different byte order?

As long as you're not working with individual bytes of integers, the endianess difference shouldn't matter since both your code and your tests are compiled for the same platform with same endianess. For testing platform specific parts you need to run the tests on the target architecture as described in the “Integration Tests” post. You can also use the byteorder crate for testing individual integer bytes in your test cases.

[arjanvaneersel]

I get the following error:

error[E0658]: use of extern prelude names introduced with `extern crate` items is unstable (see issue #55599)
   --> src/vga_buffer.rs:148:13
    |
148 |         use std::boxed::Box;
    |             ^^^
    |
    = help: add #![feature(extern_crate_item_prelude)] to the crate attributes to enable

Not clear why, also not clear where I'm supposed to put the line #![feature(extern_crate_item_prelude)]. Tried it at several places, but doesn't seem to work where ever I put it. What am I doing wrong?

[phil-opp]

@arjanvaneersel Do you have your code online somewhere so that I can take a look?

[bjorn3]

@arjanvaneersel I believe you are using edition 2018. You could add #![feature(extern_crate_item_prelude)] at the top of your lib.rs or if it doesn't work replace line 148 of vga_buffer.rs with use crate::std::boxed::Box.

[arjanvaneersel]

@bjorn3 adding #![feature(extern_crate_item_prelude)] to main.rs solved the issue.

[lilyball]

Why does this post suggest using

#[cfg(test)]
extern crate std;

instead of

#![cfg_attr(not(test), no_std)]

[lilyball]

Note that the #![cfg_attr(not(test), no_std)] approach avoids the "extern prelude names" error mentioned above.

[phil-opp]

@kballard The problem is that the core library is not in scope then, but so that the use core::[…] imports no longer work.

[lilyball]

@phil-opp Really? I went with #![cfg_attr(not(test), no_std)] and I had no problem compiling any of the rest of the code. I am using the 2018 edition (as that's what I get with cargo +nightly init right now), so I don't know if that affects anything about the core libraries (but I believe it is the source for the error that I get with #[cfg(test)] extern crate stds;).

[phil-opp]

@kballard Yeah, I think is because the 2018 edition does not require extern crate definitions, so it automatically finds the core crate in standard enabled builds too. In Rust 2015 you would need an additional extern crate core statement.

I created #500 to move this crate to the 2018 edition. As soon as we're on Rust 2018, we will use the cfg_attr approach.