1

I am currently implementing my own programming language. Until now I have written:

  • An Error class for errors (to be thrown) encountered while processing the input source code;

  • Some SyntaxError functions (each one with a different tag, passed with a template, like SyntaxError<malformed_number>() or SyntaxError<unexpected_symbol>) which help constructing Error objects with different error messages (for now I only got this, but I will soon have FunctionErrors, IndexErrors and so on);

  • A Token class which contains the informations about each token (line in the string at which it was when it was encountered, the type which can be string, number... things like that);

  • Finally, a lexer function which takes as imput a string of source code and returns a std::list<Token*> object. Internally, it uses a few helper functions (buildname, builsymbol, skipcomment...) to help mantain the code organized.

I didn't follow any particular programming technique will coding this, but I now feel the urge to follow those that go under the Test Developement Programming name.

But I have a few concerns:

  • First, what do I have to test in the above code? Of course the lexer function should be tested deeply, and maybe also the helper functions it uses (I guess), but what about the other things?

  • Second, how do I test functions with a non-trivial output? Online I see a lot of examples comparing simple numbers or strings, but how does one write a test for a function which returns a list of pointers to objects whitout having to write too much for a single test case?

user6245072
  • 303
  • 1
  • 7
  • Don't you test everything in TDD? – JeffO Sep 26 '16 at 13:59
  • @JeffO it's what I am asking. _Everything_ is pretty broad, so I want to know if I should also test constructors, minor helper functions and the like. – user6245072 Sep 26 '16 at 14:08
  • I think you should look into TDD a little more and if you don't understand what they're recommending you test, you should ask that specific question here. Your question has been asked before on this site and was considered a duplicate of another question which was closed. – JeffO Sep 26 '16 at 17:51
  • 2
    Possible duplicate of [How to know what to test in TDD?](http://programmers.stackexchange.com/questions/237065/how-to-know-what-to-test-in-tdd) – JeffO Sep 26 '16 at 17:52
  • Do you really mean "TDD" (which means coding in very small cycles, by writing a test *first*, then the code to make the test pass, then the next test, and so on)? Sounds to me you are mixing up TDD with "unit testing" or "automatic testing". – Doc Brown Sep 27 '16 at 04:08
  • @Doc Brown I want to do TDD, but the project already started and I decided to restart writing tests and (re)writing my code. But since I have already done it once it'll look very similar to the actual code, and I want to know what parts of it should be guiding me through tests. – user6245072 Sep 27 '16 at 05:17
  • If you use something like Haskell or OCAML you might eliminate the need for 50% of unit testing. Just sayin'. The end goal is a bootstrapping compiler anyway. – Den Sep 27 '16 at 10:36
  • @Den calm down, a simple interpreter is enough for now :D – user6245072 Sep 27 '16 at 11:23

1 Answers1

3

TDD is less a testing but more a coding technique. The question you need to ask here is not

"shall I test this class or not"

but

"I want to implement a small change in my code base, how can I write a test which is red before the change, and becomes green after the change"

For example, a small change might be the introduction of a new "reserved word" in your programming language. You write a test for your lexer to return a special token for this - but since you did not implement the feature, the test will fail. Then you implement the feature - test goes green. Next you refactor the code, run the test again, it gets red because you made an error. You fix that error, test goes green. Next feature: using the new reserved word in a specifically wrong manner shall return a SyntaxError exception - write a new test for this - ... - I guess you got the idea.

As you see, it does not really matter for applying TDD if there is an existing code base, or not - TDD is about verifying changes to a code base, not about testing the whole code base in each and every way.

Of course, if a code base was written without "TDD testability" in mind, it can become hard to write tests for certain changes. So if you really want to switch to TDD, it might be easier to do this early.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565