Test manifest.
parent
c00e4e3e16
commit
ba6497e5a5
|
@ -0,0 +1,26 @@
|
|||
for example:
|
||||
adding variable to context
|
||||
seting variable values by multiple assignment
|
||||
|
||||
|
||||
parsing, parsing, parsing!
|
||||
I should begin with small things. For example... designing some input files, which
|
||||
then tokenized should be parsed. Really simple stuff. And then I should check AST.
|
||||
What actually has been build? Maybe for this kind of stuff visitor patter would be appropriate.
|
||||
|
||||
Visitor as a tester... hm... it goes around and remembers data. Different kinds of visitors. Not so bad
|
||||
idea, actually. But that imposes some change in design. Actually not so bad changes.
|
||||
|
||||
So - designing input file
|
||||
parsing input, creating AST
|
||||
visiting AST, and getting data from it, comparing acquired data to data, we want to get
|
||||
|
||||
Smaller parts like creating AST Nodes. I don't know, for example some parts of parser. Maybe those parts
|
||||
should become standalone functions, to be tested more easily?
|
||||
|
||||
What's more?
|
||||
|
||||
My lexer doesn't have enough tests, i think. More tests! For example, given, acquired, desired.
|
||||
|
||||
And em, It'd be nice if I could run test from console like ./Sencha-lang --run-tests or something.
|
||||
|
Loading…
Reference in New Issue