-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add tests #27
Add tests #27
Conversation
f6c6a88
to
90b8556
Compare
Hello @vixalien |
Yes, very slowly 😭 |
Great that it's still going. there's no rush :) |
Alright, I will make something mergeable soon for a few tests, then will add more tests as time passes. Finally we will need to add some integration tests. One issue is how we will be able to run the "everything" tests. I'm not really that sure how we could build it. I will make a PR once it builds. |
Hi. I just add a simple meson configuration for the
To run the tests, do the following: meson setup build
cd build
ninja
# runs the `everything` tests
meson test everything
# you can also directly run the `everything.ts` file using the compiled `everything` library
ninja src/everything/everything.ts
In the future we can add a CI step, and add actual tests. |
We should also add the marshalling tests from https://github.com/GNOME/gobject-introspection/blob/main/tests/gimarshallingtests.c we will get automatic regression tests for arrays/booleans/everything. With that set up, it will be more easy to experiment since we will be noticing when anything gets broken. |
Update: I've added a couple regress tests in This will basically check against a library called To run them, just do:
|
things like Infinity, -Infinity, NaN undefined
47fadc6
to
86342f3
Compare
Hey, so I think this PR is partially ready. You can review it, and we will continue to implement the other parts from gitlab.gnome.org/GNOME/gjs/-/blob/fe6ef0d9f6928521592e3d1558ef5caa5e23817b/installed-tests/js/testRegress.js in other PRs so that we can iterate faster. We will need to target the whole |
Are you able to run the examples now? |
Yes i'm able to run the examples. Aren't you able to? |
No I was getting errors. |
Okay, now they are all working (except manual_loop.ts because of a typo) |
I fixed the various pre-existing regressions in #35 (which should be merged first) |
Hello! This is a draft PR that adds comprehensive tests. These tests should be run on each PR to avoid regressions by adding a GitHub workflow. This can be done later. Here's the structure I'm suggesting for the
tests/
folder:unit/
: This contains unit tests and should hopefully test each (exported) function in each file.integration/
: This should test that some processes work. Like for example, therequire
function or if therequire
functions caches namespaces. Or test unboxing and boxing of values.regression/
: This folder should be empty initially, but it should be used to add tests when there is a PR that fixes a specific issue so that the issue doesn't happen again. The files should be named according to the issue or PR number.overrides/
: This folder should be used to test the overrides in the related overrides folder (after Support overrides #10 is merged)modules/
: This should test the basic functionality of modules such asGLib.Bytes
andGtk.ListStore
.gi/
: This should contain tests that will need additional .gir and library files to run (such as GIRegress and GIMarshalling)However, I must admit that I'm not the best at doing test-related stuff, so this may not be the best approach.
Another option to consider is using a more flat directory layout and using periods (.) to structure tests, for example:
unit.base_utils.convert.ts
unit.base_utils.ffipp.ts
regression.2932.ts
overrides.GLib.ts
modules.Gtk.ts
As the tests need to be comprehensive, I will do my best to add various tests for each module, and then hopefully, it will get merged. Or we can add the initial tests boilerplate, and add tests as we go. In either case, I am longing for your feedback so I can know how to progress about this.
fixes #14
Unit tests: