Skip to content

Latest commit

 

History

History
46 lines (41 loc) · 11.8 KB

README-TESTING.md

File metadata and controls

46 lines (41 loc) · 11.8 KB

Testing Documentation

This documenatation covers the testing of the jshint, Jasmine tests, Manual tests and User Stories based tests.

  • jshint testing - I used the jshint website To test my JavaScript syntax for any harmful or potentially harmful code. Here is some examples of responses to the bundle/main.bundle.js file (the compiled JavaScript through Babel).

    • For In Loop - I found an warning on using the For In loop. On searching the error, I found other users recommended not using it for arrays. So I decided to use the usual 'i++' over array length loop. I changed multiple for loops as a result.
    • eval function - I received a warning that this can be harmful. However, many developers have told me that this issue is more to do with username and password configuration. I have been careful with my use of this function. I only used it for evaluating stringed numbers to receive an answer, and for dividing a number by 100.
    • Functions declared in loops - this warning was in relation to functions referencing outer variables, in which could cause confusion semantics. However, my project is very much related to changing global variables through various functions. Any function call backs or changes to global variables were carfully decided and any potential confusion was tested through Jasmine and Manual testing.

  • HTML tested with w3 validator.

  • CSS tested with w3 jigsaw.

  • Jasmine testing - The All tests can be read at the tests.html file. The spec files test the (1) Number Buttons; (2) Operator Buttons; (3) Keyboard Buttons; (4) Save Calculation Button; (5) Other Buttons; (6) Display Saved Calculations Function; and (7) Reusable Functions.

    • tests html file - main html file for testing, includes the html from 'index.html' file (wrapped in a div called 'hidden', in which has display styling set to 'none'). Only Jasmines testing html appears.
    • Building the test basis - First built most of the main code (i.e. for each button function or reusable function) on the main.js file. Then built the test basis of each code set with the 'Describe' function. Then built test scenarios related to the button or calling of a function.
    • Test scenarios - For most scenarios I would reset the related global variables to their correct setting that fits each, i.e. calculation array could be set to "['5' 'x' '6']". The 'expect' function could be used to test the calling of a function's outcomes or non outcomes ( i.e. 'expect(num4.onclick().toBe('4'))' or 'expect(clearAll()).not.toBe(true)'). I would also test all the global variables to make sure they have changed or haven't changed (i.e. expect(calculation).toEqual([]) and/or expect(disableDec).toBe(false);). I would do as much tests as I need on each related element of code in each function.
    • Refactoring the code - I would would have each expect test fail, pass it and then maybe refactor the code being tested. The more tests I built the more faults or errors I would come across in the code, which required me to refactor the code. Further more, when I moved onto another button function to test, I would sometimes find I need to add to the previous code of other functions. This was the case when I built and tested the operator utiliser function, in which I would also built and tested the 'pushToCalculation' function. I found after building them I needed to go back to the number building function, to make sure it would push the newOperator data into the calculation when it was needed.
    • Running the tests - done in linear order and not at random. This was because each each test is built as a separate scenario and becuase when testing them at random, errors would occur. Whether or not these tests run at random is irrelevent to the collection of tests beacuase they are not necessarily connected.
    • Longer 'it' functions - Some of the 'it' functions were very long. They had multiple expect tests and calling of functions. They would usually embody a pattern of interaction to the DOM to see multiple responses. Due to the amount of code, I would usually write longer descriptions of the it functions. The testing files 'saveCalcButtonSpec.js', 'keyboardButtonsSpec.js', 'otherButtonSpec.js' are clear examples of this. As a future development, I may rewrite these tests to keep them more clear.
    • Testing 'displaySavedCalculations()' function - I had to split one of my 'it' tests into two 'it' tests due to a timing issue from pressing the deleteCalc button (because it uses a setTimeout to allow time for an animation/transition to pass, and then recalls displaySavedCalculations()). Prior to the 'it' test that calls the deleteCalc button, I called both beforeEach() and afterEach() functions, with the former creating a jasmine spy on the displaySavedCalculations() function, then installing a jasmine clock, and the latter uninstalling the jasmine clock. Then when the next 'it' function is called, it innitially calls deleteCalc.onclick(). After this I delayed the next tests with a setTimeout of 500 miliseconds and then called jasmine.clock().tick(501). This corrected the timing of the next test. I discovered this process through this link
    • scrollToTop() function hasn't been testing - this was the only function which wasn't tested. This was because it is not code I developed myself and because (it was from stackOverFlow.) I felt manually testing was enough testing for it. It is also quite complex for Jasmine testing. For a future development on this, I may test it.

  • Manual testing.

    • While building each button, I would also test the calculator manualy from the chrome browser. After compiling the code into the build/main.bundle.js through babel, I would test the calculator on chrome, firefox and safari browsers, to make sure it is compatable with all browsers.
    • I tested every button click, and buttons response to see if any errors came up in the browser.
    • Manual testing was valuable for testing transitions/animations, because any problems with them are visible to the eye. The origin scrollToTop function was not working (from previous commits) in Safari before. The current code for it is more complex but now works.
    • I tested margins, sizes and paddings on every browser in which I tested each from its minimal mobile size browser. For Safari browsers, it was important that I tested a minimal screen width of 320px. The width of 304px in Chrome usually equals 320px in Safari, so I tested 304px as the minimum screen size.

  • Reviewing User Stories - I reviewed my user stories and tested my application to see if it meets the requirements.

    • Both the Calculator and Calculation Backup section fully functional upon loading the webpage.
    • I can build a long calculations from pressing the buttons on the calculator and using keyboard keys. Calculations are evaluated by clicking the equals button, or pressing the keyboard keys 'Enter', 'Return' or '='.
    • I can view my built calculation in the small screen on the calculater. I can see the entire calculation as long as its length doesnt exceed the width of the calculator screen. I can atleast see the end of the calculation at all times, in which shows my last inputed data.
    • If my calculation is too long for the calculator screen, I can still view it in full in a separate larger screen, when I click the 'Show Full Calculation' button. The calculator tells me where to find the full calculation after I clicked this button. I can hide the full screen by pressing the button again, in which brings the calculation back to the calculator display. I can consistantly toggle between the two screens by clicking this button.
    • I can remove the last inputs from the displayed input and/or displayed calculation, by clicking the 'remove' button. When I click this button multiple times in a row, in keeps removing the last two elements of the built calculation and will always leaves a number as the last inputed element until it completely clears the calculation. The button always leaves the message "removed" when clicked and when it clears the calculation it will leave a "cleared" message on the calculator or enlarged display screen.
    • I can completely clear the entire calculation and next inputs by clicking the "clear" button. After clicking this button it leaves the message "cleared" and number 0 in the input section. I can start a new calculation when I press the button.
    • I can build a number as long as the width of the calculator screen by pressing the number buttons. Once the built number exceeds its number length it messages me telling me it "exceeds limit".
    • I can utilise a plus, multiply, substract or divide operator, by clicking their respective buttons, and continuously change my choice of the four operators, when clicking each.
    • When I press a number or operator button, I can always see the changes appear on the screen. After each button press, the input and/or built calculation changes.
    • The built number or operator remains separate to the main built calculation, until I switch from one to the other. When I press an operator button, after building a number, the number is pushed into the built calculation. When I press a number button, after utilising an operator, the operator is pushed into the calculation.
    • After evaluating the calculation, an equals sign ("=") appears at the end of the evaluated calculation telling me it had been evaluated, and the answer to the evaluation appears below the built calculation. I can use this answer as my first number for my next calculation, by pressing an operator number, or I can restart a brand new calculation by pressing a number button.
    • I can switch a built number to its negative or positive opposite by clicking the 'plus-minus' button (±) on the calculator. For example, the number 5 would turn to -5 after clicking, and it will turn back to 5 when clicked again. Wether the number is a possitive or negative, I can push it to the calculation in its current state when I press an operator number.
    • I can divide my built number by 100 by clicking the 'divide by 100' button (%). I can divide the number as many times as I want, and the number can be pushed into the calculation when I start using an operator.
    • I can save my calculator data and settings, and keep it stored as long as the webpage is not closed or reloaded. Each saved calculation can be found in the form of a list/box of a 'saved calculation' items. Within each list item, I can see my saved calculations and data inputs/evaluated answers. Prior to saving a calculation, I can write a description of the calculation data within a 'textarea' input. As long as their is text typed into the textarea, the text will be included in the saved list item's details. I can save up to 10 saved calculation items. After saving 10 items, I can't save anymore, until I delete one or more of the items.
    • Within each saved item, I can find a load button, in which on clicking, reloads my saved calculator progress. After loading the calculator progress, I can continue working on the calculation. I can save my calculation progress again as a new saved list item.
    • Within each saved item, I can find a delete button, in which on clicking, removes the item data and its display.
    • Upon clicking 'Save Calculation', 'Delete' and 'Load' buttons, I am clearly alerted they have been activated through a combination of different message alerts (above each section), styling changes and animations/transitions.
    • If an item is loaded and the calculator is off screen, the screen scrolls me back to the calculator showing the loaded data.