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@mail.langsec.org
https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
_______________________________________________
langsec-discuss mailing list
langsec-discuss@mail.langsec.org
https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
