-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
discussion: adopt baretest-like testing API #4092
Comments
Just to clarify - This issue is about addition of |
It would be nice if we could add these hooks while still using Here's an idea: let resourceSnapshot;
const s = new Deno.TestScope("my test suite", {
beforeEach() {
resourceSnapshot = Deno.resources();
},
afterEach() {
const resources = Deno.resources();
// diff with `resourceSnapshot` and ensure test
// doesn't leak resources
assertEquals(resourceSnapshot, resources, "test leaks resources");
}
});
s.start();
Deno.test({
name: "foobar",
fn() {
// ...
}
});
// TODO: fixme, temporary disabled
Deno.test({
skip: true,
name: "fizzbuzz",
fn() {
// ...
}
});
s.end(); |
Maybe i'm confused, but what about making Jest deno compliant ? is it too much work ? |
@nayeemrmn @ecyrbe Definitely; Jest has >50k lines of code and has >70 deps which are mostly Node specific. Besides it's full-blown testing framework with snapshots, mocking, etc. |
Bringing these hooks to Deno itself is fine I believe since they are truly minimal. @nayeemrmn I think your proposal could be confusing, since there is no clear association between @ecyrbe Jest is just too huge a framework to port. To be honest I would rather put such effort to std/node polyfills than for Jest itself :) (maybe with enough Node polyfills we can get it work) |
@bartlomieju How about giving it as an option to let resourceSnapshot;
const suite = new Deno.TestSuite("my test suite", {
beforeEach() {
resourceSnapshot = Deno.resources();
},
afterEach() {
const resources = Deno.resources();
// diff with `resourceSnapshot` and ensure test
// doesn't leak resources
assertEquals(resourceSnapshot, resources, "test leaks resources");
}
});
Deno.test({
name: "foobar",
suite,
fn() {
// ...
}
});
// TODO: fixme, temporary disabled
Deno.test({
skip: true,
suite,
name: "fizzbuzz",
fn() {
// ...
}
}); Or have let resourceSnapshot;
const suite = new Deno.TestSuite("my test suite", {
beforeEach() {
resourceSnapshot = Deno.resources();
},
afterEach() {
const resources = Deno.resources();
// diff with `resourceSnapshot` and ensure test
// doesn't leak resources
assertEquals(resourceSnapshot, resources, "test leaks resources");
},
tests: [
Deno.test({
name: "foobar",
fn() {
// ...
}
}),
// TODO: fixme, temporary disabled
Deno.test({
skip: true,
suite,
name: "fizzbuzz",
fn() {
// ...
}
})
]
}); Too many indents, probably. These are just examples of strategies to make |
@nayeemrmn IMHO I don't think adding a separate Actually, I am actually thinking about making |
@bartlomieju Another silly question : so what about mocha + jspm as mocha does not rely on node and can run in the browser, and deno is almost like a browser : https://mochajs.org/#running-mocha-in-the-browser |
@ecyrbe you can already run mocha with Deno; example in |
@bartlomieju So we already have access to mocha hooks ? why not use them ? |
@bartlomieju Actually I just noticed that deno is panicking if you try to import |
@ecyrbe Deno core should offer a set of bare minimal utilities, instead of being too opinionated IMO |
@bartlomieju Thanks, that clarifies everything. So i guess what deno expose today is sufficiently deadly simple and maybe we should orient users to use more complex libraries when needing advanced testing functionnality. What i dislike here is adding another way to write deno native tests. If hooks are really necessary, i would then advise going all in and remove Deno.test() api. |
I agree - we should either provide only the dead simple |
Personally, I don't feel we need to introduce a class to make all this happen. How are capabilities like test setup and teardown work in Rust? That model seems to be very effective for us. I believe there is effectively block of code that are only included in the final binary and run when you do a test build, and the implementation of anything fancy is left up to the implementor. I think we should really think minimalistic, otherwise we will be in the test harness business, not the JavaScript/TypeScript runtime business. |
I agree with @kitsonk that we don't need setup/teardown. Rust's unit tests are a great example of this - they provide no such facility - and yet we're able to build very complex software on top of it. We will not be introducing a more complex test facility for Deno. It should be simply registering functions to be run and checking if they get exceptions. |
I agree that keeping it minimal, but as I think Go is resolving the problem well by providing run hook. func setup() {
println("setup")
}
func teardown() {
println("teardown")
}
func TestMain(m *testing.M) {
setup()
ret := m.Run()
teardown()
os.Exit(ret)
} |
You can write your own. I have used something like: export async function test(t: Deno.TestDefinition) {
async function wrapped() {
await setUp();
try {
await t.fn();
} finally {
await tearDown();
}
}
Deno.test({ name: t.name, fn: wrapped });
} Perhaps something to aid that could be in std, but it's not necessary in Deno namespace. |
I have reached to this issue searching for support for Deno.test({
name: "example test",
fn: [
function test1() {
assertEquals("hello", "hello");
},
function test2() {
assertEquals("world", "world");
}
],
beforeEach() {
// Code to execute before each test function
},
afterEach() {
// Code to execute after each test function
},
beforeAll() {
// Code to execute before all test functions are executed
},
afterAll() {
// Code to execute after all test functions are executed
}
}); |
How about adding Deno.test("suite", () => {
// beforeAll
const tests = [
{
name: "test1",
fn: () => {
…
}
},
{
name: "test2",
fn: () => {
…
}
}
]
for await (const test of tests) {
// beforeEach
await Deno.test(test)
// afterEach
}
// afterAll
}) console: test suite
test test1 ... ok
test test2 ... ok That way we would be able to implement the upper described functionality without adding any new syntax. |
@timreichen I think that's a really nice solution :-) Can you open a new issue? Use the code example more like the one here: https://discord.com/channels/684898665143206084/684911491035430919/762300901590433812. |
Here is a wrapper I implemented for adding test setup/teardown to |
baretest
is pretty interesting project that implements very simple testing framework (I wouldn't even call it a framework). It has a few functionalities which seem to be very desirable:beforeAll
/afterAll
hooks - can be used to setup expensive stuff before testing (DB connections, net connections, etc.)before
/after
hooks - can be used to implement useful sanity check, eg: verify that test closes all resources it opens; verify there are no pending ops when test finishesFull code would look something like:
And API:
Ref #4090
The text was updated successfully, but these errors were encountered: