60e2149072
Tasks 16-20: Online Board Tests (Search/Filter, Tabs, Flight List, Details Modal, Time/Date) - Task 16: Search & Filter tests (37 tests) - departure/arrival cities, passenger count, cabin class - Task 17: Arrival/Departure Tabs tests (45 tests) - tab switching, flight display, sorting - Task 18: Flight List View tests (50 tests) - display, sorting, filtering, pagination, loading states - Task 19: Flight Details Modal tests (40 tests) - opening/closing, content display, actions - Task 20: Time & Date Filter tests (43 tests) - date selection, time ranges, calendar navigation Tasks 21-25: Flight Details Tests (Flight Info, Passengers, Seats, Services, Fares) - Task 21: Flight Info Display tests (40 tests) - basic info, airports, route visualization, timeline - Task 22: Passenger Info tests (50 tests) - passenger list, details, services, special requirements - Task 23: Seat Selection tests (50 tests) - seat map, selection, categories, recommendations - Task 24: Service Selection tests (25 tests) - baggage, meals, seats, summary - Task 25: Fare Display tests (55 tests) - fare breakdown, comparisons, discounts, refunds All tests follow AAA pattern and use data-testid selectors matching Angular version. Total: 245 tests across 10 feature suites.
31 lines
2.0 KiB
Markdown
31 lines
2.0 KiB
Markdown
# performance-now [](https://travis-ci.org/braveg1rl/performance-now) [](https://david-dm.org/braveg1rl/performance-now)
|
|
|
|
Implements a function similar to `performance.now` (based on `process.hrtime`).
|
|
|
|
Modern browsers have a `window.performance` object with - among others - a `now` method which gives time in milliseconds, but with sub-millisecond precision. This module offers the same function based on the Node.js native `process.hrtime` function.
|
|
|
|
Using `process.hrtime` means that the reported time will be monotonically increasing, and not subject to clock-drift.
|
|
|
|
According to the [High Resolution Time specification](http://www.w3.org/TR/hr-time/), the number of milliseconds reported by `performance.now` should be relative to the value of `performance.timing.navigationStart`.
|
|
|
|
In the current version of the module (2.0) the reported time is relative to the time the current Node process has started (inferred from `process.uptime()`).
|
|
|
|
Version 1.0 reported a different time. The reported time was relative to the time the module was loaded (i.e. the time it was first `require`d). If you need this functionality, version 1.0 is still available on NPM.
|
|
|
|
## Example usage
|
|
|
|
```javascript
|
|
var now = require("performance-now")
|
|
var start = now()
|
|
var end = now()
|
|
console.log(start.toFixed(3)) // the number of milliseconds the current node process is running
|
|
console.log((start-end).toFixed(3)) // ~ 0.002 on my system
|
|
```
|
|
|
|
Running the now function two times right after each other yields a time difference of a few microseconds. Given this overhead, I think it's best to assume that the precision of intervals computed with this method is not higher than 10 microseconds, if you don't know the exact overhead on your own system.
|
|
|
|
## License
|
|
|
|
performance-now is released under the [MIT License](http://opensource.org/licenses/MIT).
|
|
Copyright (c) 2017 Braveg1rl
|