[langsec-discuss] Test cases in the same language as the application being tested

Falcon Darkstar Momot falcon at iridiumlinux.org
Sun Dec 11 23:52:26 UTC 2016

One could take it a step further, even, and suppose that you also can't 
write test cases within the grammar implied by the unparsing logic of 
your application under test.  Clearly, placing constraints on the 
generation of test cases /at all/ reduces the effectiveness of testing - 
there's no magic about the language the program under test is written in.

My own preference is to use a low-level language to generate test 
cases.  If an application is tested without having any testing framework 
capable of sending a binary blob into the application, I'd suppose that 
it's incomplete.

--Falcon Darkstar Momot

On 11/12/2016 13:40, Nils Dagsson Moskopp wrote:
> Recently, I wanted to write a test case that I was sure would lead to an
> error in the application. Yet, I could not, as the testing framework was
> written in the same programming language as the application, lacking the
> expressiveness needed for the test case. Then that thing happened again.
> Example: Mocking requests that contain U+2028 or U+2029 from JavaScript.
> Those characters are valid in JSON, but not in JavaScript … if your test
> framework is written in JavaScript, how do you even mock these requests?
> I believe there might be some lesson about the power of languages hidden
> in my experience, but I am not sure what exactly it would be. It reminds
> me of Kerningham's lever (The Elements of Programming Style, Chapter 2):
>> Everyone knows that debugging is twice as hard as writing a program in
>> the first place. So if you're as clever as you can be when you write
>> it, how will you ever debug it?
> Greetings,
> _______________________________________________
> langsec-discuss mailing list
> langsec-discuss at mail.langsec.org
> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20161211/1116d9e8/attachment.html>

More information about the langsec-discuss mailing list