-
Notifications
You must be signed in to change notification settings - Fork 4
Add lc-test.js #64
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 lc-test.js #64
Conversation
example/test.js
Outdated
config.purity = "Let"; | ||
config.numEncoding = "Church"; | ||
const toInt = toIntWith(config); | ||
const { counter } = compile(solution()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe getSolution()
is better? Or solutionCode
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think getSolution()
or readSolution()
is better. It makes it more natural if an author needs to work with a solution text more than just compiling, using const solution = readSolution()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hadn't realised solution
would clash with const solution = compile(solution())
, but I do that in several bigger kata.
getSolution
has my vote.
I have a proposal for configure
in which toInt
is differently than it is used here.
workspace/test.js
Outdated
@@ -1,13 +1,9 @@ | |||
import { assert, config as chaiConfig } from "chai"; | |||
chaiConfig.truncateThreshold = 0; | |||
import { assert, config, toIntWith, compile, solution } from "./lc-test.js"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does ./lc-test.js
also have to be local? (I suppose so, for the same reason as ./files.js
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want, we can move import.meta.url
to test.js
instead:
export const getSolution = (base) => readFileSync(new URL("./solution.lc", base), {encoding: "utf8"});
// or general
export const getRelative = (base, file) => readFileSync(new URL(file, base), {encoding: "utf8"});
import { getSolution, getRelative } from "@codewars/lambda-calculus/test";
const { counter } = compile(getSolution(import.meta.url));
const { counter } = compile(getRelative(import.meta.url, "./solution.lc"));
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm no that doesn't seem very pleasant. I think its fine with just ./lc-test.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like ./lc-test.js
.
Would not ./lc-tests.js
completely obviate the need for a separate ./files.js
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, files.js
doesn't exist anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Karott and I decided on some redesign; I'm implementing that now and I'll incorporate the workspace redesign as well. It's all interconnected or tests will fail.
workspace/test.js
Outdated
@@ -1,13 +1,9 @@ | |||
import { assert, config as chaiConfig } from "chai"; | |||
chaiConfig.truncateThreshold = 0; | |||
import { assert, config, toIntWith, compile, solution } from "./lc-test.js"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like ./lc-test.js
.
Would not ./lc-tests.js
completely obviate the need for a separate ./files.js
?
I have tried to do everything from this PR in mine. If I did that right, this one can be summarily rejected. I just don't know if I did. |
Reduce boilerplate. More helpers can be added in the future.