Running Test Suites and playing with ECMA Standards
In this lab, we looked into language standards, as well as testing test suites for the first time. Additionally, simple tests were contributed, with the possibility of posting as a contribution if need be. Here are some questions that cover the work that was done;
1- When you run the tests, do all the tests pass or do any of them fail for you?
After following the instructions and forking over the repo from https://github.com/bterlson/test262-harness#test262-harness, the "test262-harness test/**/*.js" command let me find out which tests would pass and fail. After a short compilation of the tests, I've found out that out of 205 tests, 199 passed and 6 failed. The failed tests concerned 'locale' related errors for the most part.
2- Examining existent test 'https://github.com/tc39/test262/blob/master/test/built-ins/String/prototype/toUpperCase/S15.5.4.18_A2_T1.js' and providing observations
The sets of tests ran by this code include some defined conventions as follows;
- Naming: the names need to be understandable and intuitive. Furthermore, the names need to be numbered by a specific way to differentiate tests.
- Test Style: In terms of format, the tests must include the copyright header, followed by a description, and finally, the code.
- Error Handling: Every expected run time errors will need to be marked with a throw declaration using the appropriate Error Constructor Function.
Keeping this set of rules in mind, when observing the test code mentioned above, I observed;
- Naming: The code describes what the tests are used for perfectly. These tests are meant to compare uppercase strings together and that's exactly what it does.
- Test Style: The format was followed to the letter, and additionally, some backslashes meant for delimiting the code was added as well for better visibility.
- Error Handling: Although deprecated, the code uses the $ERROR statement, which works equally fine, but seems like it should be updated.
3- What sort of things could you test with Array.reverse? Based on what you read about its description, what sort of things need to be true about how Array.reverse works?
Description; https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.reverse
My initial thought was how surprised I was to see how minimal information there was about the actual method. Since it seemed like it was meant to reorder numbers, I wondered if it could do that in an array that had a string as part of the numbers, and if so, how those numbers would be reordered if the said string would be in the middle of the array. That ended up being what I wanted to test.
Based on description, there are basic requirements that need to be met. For example, array length must be above 0, middle is defined as low(floor/2), etc...
4- Comparing test code between https://github.com/tc39/test262/tree/a62da2b4997767a78bb2834c4fbf4e598b0fc241/test/built-ins/TypedArray/prototype/reverse and https://github.com/tc39/test262/tree/a62da2b4997767a78bb2834c4fbf4e598b0fc241/test/built-ins/Array/prototype/reverse with observations.
Following the previous steps, I have more knowledge about how the testing works, so I compared and analyzed the mentioned two sets of tests to see what's similar;
I found that generally speaking, the conventions are all adhered to. Some of the test functions from both folders can get fairly extensive, some are very short to test more simple functionality. Overall, the descriptions are always informative enough to understand what's going on without too much effort.
One thing I would change from some of the tests i've seen is the usage of the $ERROR statement, like mentioned in Question 2, it is deprecated. Some newer tests make use of the assert statement which is the updated way to do it, but there are still tests using the deprecated statement.
1- When you run the tests, do all the tests pass or do any of them fail for you?
After following the instructions and forking over the repo from https://github.com/bterlson/test262-harness#test262-harness, the "test262-harness test/**/*.js" command let me find out which tests would pass and fail. After a short compilation of the tests, I've found out that out of 205 tests, 199 passed and 6 failed. The failed tests concerned 'locale' related errors for the most part.
2- Examining existent test 'https://github.com/tc39/test262/blob/master/test/built-ins/String/prototype/toUpperCase/S15.5.4.18_A2_T1.js' and providing observations
The sets of tests ran by this code include some defined conventions as follows;
- Naming: the names need to be understandable and intuitive. Furthermore, the names need to be numbered by a specific way to differentiate tests.
- Test Style: In terms of format, the tests must include the copyright header, followed by a description, and finally, the code.
- Error Handling: Every expected run time errors will need to be marked with a throw declaration using the appropriate Error Constructor Function.
Keeping this set of rules in mind, when observing the test code mentioned above, I observed;
- Naming: The code describes what the tests are used for perfectly. These tests are meant to compare uppercase strings together and that's exactly what it does.
- Test Style: The format was followed to the letter, and additionally, some backslashes meant for delimiting the code was added as well for better visibility.
- Error Handling: Although deprecated, the code uses the $ERROR statement, which works equally fine, but seems like it should be updated.
3- What sort of things could you test with Array.reverse? Based on what you read about its description, what sort of things need to be true about how Array.reverse works?
Description; https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.reverse
My initial thought was how surprised I was to see how minimal information there was about the actual method. Since it seemed like it was meant to reorder numbers, I wondered if it could do that in an array that had a string as part of the numbers, and if so, how those numbers would be reordered if the said string would be in the middle of the array. That ended up being what I wanted to test.
Based on description, there are basic requirements that need to be met. For example, array length must be above 0, middle is defined as low(floor/2), etc...
4- Comparing test code between https://github.com/tc39/test262/tree/a62da2b4997767a78bb2834c4fbf4e598b0fc241/test/built-ins/TypedArray/prototype/reverse and https://github.com/tc39/test262/tree/a62da2b4997767a78bb2834c4fbf4e598b0fc241/test/built-ins/Array/prototype/reverse with observations.
Following the previous steps, I have more knowledge about how the testing works, so I compared and analyzed the mentioned two sets of tests to see what's similar;
I found that generally speaking, the conventions are all adhered to. Some of the test functions from both folders can get fairly extensive, some are very short to test more simple functionality. Overall, the descriptions are always informative enough to understand what's going on without too much effort.
One thing I would change from some of the tests i've seen is the usage of the $ERROR statement, like mentioned in Question 2, it is deprecated. Some newer tests make use of the assert statement which is the updated way to do it, but there are still tests using the deprecated statement.
Comments
Post a Comment