Manual testing

Proper operation can be seen through key stages in a demonstration video linked below. These stages have been tested manually. Currently, there are 26 stages to confirm proper operation. These have been split into 5 main categories:

Interface

• Interactive Execution
• Reorder Cards
• Collapse and Expand Inputs and Outputs on the Cards and the Card itself
• Delete and Undo Deletion of Cards
• Edit Titles of Cards
• Search Cards
• Regular Expression (RegEx) Search

Outputs

• Render Images
• Render SVGs
• Render Tables
• Plot Graphs
• Support for Library Functions
• Render and Edit Markdown cards
• R Support
• Latex Support
• PDF Support
• Interactive Output Pane
• GeoJSON Support

Data Analysis

• Example Usage

Smart Imports

• Automatically Detect and Import Modules/Libraries
• Automatically Detect and Install Dependencies

Jupyter Integration

• Select Multiple Cards to Delete
• Export Cards to Jupyter
• Import Jupyter Notebooks
• Re-Order Imported Jupyter Cells
• Export Modified Cells back to Jupyter

Unit tests

The front-end (user interface) and backend (background logic) side of the application have 46 and 24 unit tests written for each respectively, for a total of 70 tests.

These tests are used to ensure functionality of each individual (unit) module. For example, ensuring that a particular component works on its own is of paramount importance when debugging an issue, especially when multiple components depend on one another. Having the knowledge that one component works fully can speed up the debugging process dramatically.

Furthermore, these tests were used in a continuous integration process. These enabled each individual to fully test their code before integrating it with the main branch, ensuring there were no bugs. An example would be running these tests after developing the desired feature, and checking if the tests still pass. This established a baseline of functionality for the application, as each test would have to be passed before it could be merged with the main branch.

Front-end

As with the design specification, the neuron extension is built in Typescript, with Angular CLI working alongside as the front-end framework. The modular structure of the front-end components allows well-organised unit-testing for features performance and maintenance before actual publication.

The Angular CLI has Jasmine Test Framework integrated for testing purposes, with the karma test runner iterating over our test scripts, each targeting one modular component. The total 46 front-end unit tests are organised under main functionality as follows:

AnsiColorizePipe

• Does not modify string
• Does not modify plain text
• Renders foreground colors
• Renders multi-attribute sequences

CardComponent

• Card component should be created
• OnMove emitter should output inputted string when function is called
• Selecting card should emit true via onSelect event emitter
• When select button is clicked select function should be called
• When delete is clicked onDelete event emitter should emit
• When clicking up should call move() with arguments "up"
• When clicking down should call move() with arguments "down"
• When clicking editing title editing title property should change
• Clicking collapse button should set ediing title to be false
• After editing title, pressing enter should set editing title to false
• After editing title, pressing esc should set editing title to false
• When clicking accept button the title property should be false
• When clicking card collapse button card.collapse property should change

CustomMarkdownComponent

• Clicking startEdit should set editing markdown to true
• Clicking cancel button should keep card source code
• Clicking finished markdown button should set editing markdown to false and modifies source code

HighlightPipe

• Highlights single character
• Highlights single word
• Highlights case-insensitive single character
• Highlights case-insensitive multiple word
• Highlights simple regex query
• Highlights simple regex query with no flags
• Highlights regex special characters

MathComponent

• $ Characters should be replaced with space
• Normal Characters should not be replaced

PreviewPipe

• Case length = 0
• Case length = 50
• Case length = 51
• Case length = 101

RegexService

• Regex query should return null if search query is a normal string
• Regex query should return null if search query is a normal string, even with slash at front
• Regex query should return null if search query is a normal string, even with slash at end
• Regex query should return regex expression if search query is enclosed /.../, with no flags
• Regex query should return regex expression and flags if search query is enclosed /.../flags

ToolbarComponent

• Toolbar component should be created
• Filters should be initialized to all true at startup
• EventEmitter emit given search query and filter state
• Toolbar should contain text: plain text
• Search input should bind to the searchQuery variable
• Checkboxes should be intialized to be true once user has entered value in search
• Checkboxes should be be linked to filterstate variable
• Eventemitter should emit inputted search query once query has been inputted

Backend

Backend tests were achieved through running a special instance of VS Code, the Extension Development Host. The back end unit tests can also be referred to as integration test. This was because access to the full VS Code api was required, as the functionality go beyond unit tests that can run in isolation from a VS Code window.

These unit tests utilise the mocha framework in conjunction with the VS Code API.

The tests follow the official testing guide from Microsoft VS code, which can be found here VS Code Testing.

CardManager Tests

• Adding card to cards array works - addCard()
• Move cards up works - moveCardUp()
• Move cards up works even with 1 card -moveCardUp()
• Move cards down works - moveCardDown()
• Move cards down works with one card - moveCardDown()
• Delete card works - deleteCard()
• Change title test - changeTitle()
• collapseCode()
• collapseOutput()
• collapseCard()
• getCardId()
• addCustomCard()
• editCustomCard()

ContentHelper Tests

• Make title from source code
• Make title from source code with function
• Make title from source code with multiple brackets
• Install module calls terminal correctly
• Increment ID works
• Checking interpret rich function
• Checking interpret rich function text/plain
• Checking interpret rich function vnd.jupyter
• Checking interpret rich function vnd.jupyter
• Checking interpret rich function image/jepg
• Checking interpret rich function application/vnd.plotly.v1+json

Further improvement

For software testing, there can and always will be more to do. As a group, the consensus was reached to develop a balance between implementing new features to meet the client’s needs and enforcing existing code through tests. In the future, it is more than likely that more tests will be added to extend the code coverage.