1,093 Matching Annotations
  1. Jan 2022
    1. Tigran Avoundjian. (2022, January 3). Increases in hospitalizations routinely lag behind cases by a week (sometimes more). Deaths have an even longer lag. On 12/30, we had seen a 56% increase in 7-day hospitalization counts, and today we are seeing an 81% increase week-to-week. We have already passed the Sept peak. [Tweet]. @avoundji. https://twitter.com/avoundji/status/1478092404091588608

    1. This was because dynamic typing doesn’t give the safety net that static typing does. So you write more tests. Which is a good thing.

      Tests are a good thing, but not all devs are even aware of the loss of safety net and so there's no guarantee that using a dynamic language results in more tests.

      Using tests and static-types together would mean that there's whole categories of bugs that get eliminated while also getting more coverage for less lines of test-code.

  2. Dec 2021
    1. Arieh Kovler. (2021, November 26). Israel has identified four cases of the B.1.1.529 variant, all recent travellers. One case, a 32-year-old woman returning from South Africa, was triple vaccinated with Pfizer and had her 3rd dose just two months ago. [Tweet]. @ariehkovler. https://twitter.com/ariehkovler/status/1464190991204859919

    1. Kim Willsher. (2021, December 16). Let’s try again...new “drastic” regulations for anyone planning to come to France from UK. There must be a “compelling” reason. This does not include tourism or business French nationals/residents can return but must have a negative Covid test within 24hrs before departure. 1/2 [Tweet]. @kimwillsher1. https://twitter.com/kimwillsher1/status/1471401803828764682

    1. Tom Moultrie. (2021, December 17). A 1-figure Gauteng update, bringing in data through Wednesday 15/12 (PCR only; by date of collection). The turn continues. On similar metrics (not shown) ALL northern provinces (NW, GT, MP, LP) seem to have now turned. Https://t.co/6Bh3kZsooK [Tweet]. @tomtom_m. https://twitter.com/tomtom_m/status/1471723711287996416

    1. Jay Varma. (2021, December 16). Um, we’ve never seen this before in #NYC. Test positivity doubling in three days 12/9—3.9% 12/10—4.2% 12/11—6.4% 12/12—7.8% Note: Test % is only for PCR & NYC does more per capita daily than most places ~67K PCR/day + 19K [reported] antigen over past few days (1/2) https://t.co/PhxsZq55jn [Tweet]. @DrJayVarma. https://twitter.com/DrJayVarma/status/1471485885447389186

    1. Interactive storiesStorybook enables you to capture various states of a component in a structured format called a story. Each story simulates a particular UI state by rendering the component in isolation and supplying props and mock data.However, some UI states can only be reached via user interaction—click, drag, tap, type, etc. These were previously impossible to model in Storybook. To address this, we've added a new construct in Storybook 6.4 called the play function. That enables you to run scripted interactions after a story is rendered.Consider this play function that fills out a form to trigger a validation:

      I wonder how this can change how we approach component testing / unit tests?

    1. Tom Moultrie. (2021, December 12). Given the comedic misinterpretation of the South African testing data offered by @BallouxFrancois (and many others!) last night ... I offer some tips having contributed to the analysis of the testing data for the @nicd_sa since April last year. (1/6) [Tweet]. @tomtom_m. https://twitter.com/tomtom_m/status/1469954015932915718

  3. Nov 2021
    1. You can think of a test as being broken down into four steps: Arrange Act Assert Cleanup Arrange is where we prepare everything for our test. This means pretty much everything except for the “act”. It’s lining up the dominoes so that the act can do its thing in one, state-changing step. This can mean preparing objects, starting/killing services, entering records into a database, or even things like defining a URL to query, generating some credentials for a user that doesn’t exist yet, or just waiting for some process to finish. Act is the singular, state-changing action that kicks off the behavior we want to test. This behavior is what carries out the changing of the state of the system under test (SUT), and it’s the resulting changed state that we can look at to make a judgement about the behavior. This typically takes the form of a function/method call. Assert is where we look at that resulting state and check if it looks how we’d expect after the dust has settled. It’s where we gather evidence to say the behavior does or does not align with what we expect. The assert in our test is where we take that measurement/observation and apply our judgement to it. If something should be green, we’d say assert thing == "green". Cleanup is where the test picks up after itself, so other tests aren’t being accidentally influenced by it. At it’s core, the test is ultimately the act and assert steps, with the arrange step only providing the context. Behavior exists between act and assert.
    1. I suggest renaming this to something like SomeInterfaceAsTypeWrittenByHand. Because one of the reasons for Simplify is so you don't have to write SomeType by hand. Then add the following to show that Simplify<SomeInterface> is the same as SomeInterfaceAsTypeWrittenByHand. declare const a: Simplify<SomeInterface>; expectType<SomeInterfaceAsTypeWrittenByHand>(a); // Interface is assignable to its Simplified type (created with Simplify, and by hand) expectType<Simplify<SomeInterface>>(someInterface); expectType<SomeInterfaceAsTypeWrittenByHand>(someInterface);
    1. ReconfigBehSci. (2021, October 30). Does there maybe need to be more distinction between points raised for discussion and any actual decision? Without knowing about votes etc., it’s maybe a bit strong to say ‘JCVI wanted x...’? I’ve sat on many bodies with minutes documenting positions I disagreed with [Tweet]. @SciBeh. https://twitter.com/SciBeh/status/1454488759785897987

  4. Oct 2021
  5. Sep 2021
  6. Aug 2021
  7. Jul 2021
    1. Fixtures are created when first requested by a test, and are destroyed based on their scope: function: the default scope, the fixture is destroyed at the end of the test.

      Fixtures can be executed in 5 different scopes, where function is the default one:

      • function
      • class
      • module
      • package
      • session
    2. When pytest goes to run a test, it looks at the parameters in that test function’s signature, and then searches for fixtures that have the same names as those parameters. Once pytest finds them, it runs those fixtures, captures what they returned (if anything), and passes those objects into the test function as arguments.

      What happens when we include fixtures in our testing code

    3. “Fixtures”, in the literal sense, are each of the arrange steps and data. They’re everything that test needs to do its thing.

      To remind, the tests consist of 4 steps:

      1. Arrange
      2. Act
      3. Assert
      4. Cleanup

      (pytest) fixtures are generally the arrange (set up) operations that need to be performed before the act (running the tests. However, fixtures can also perform the act step.

    1. Testing at GitLab is a first class citizen, not an afterthought. It’s important we consider the design of our tests as we do the design of our features.
    1. It’s fun but when would we ever use things like this in actual code?When it’s well tested, commented, documented, and becomes an understood idiom of your code base.We focus so much on black magic and avoiding it that we rarely have a chance to enjoy any of the benefits. When used responsibly and when necessary, it gives a lot of power and expressiveness.
  8. Jun 2021
    1. Christophe Fraser 💙 on Twitter: “Reading Cummings accounts of early creation of Test & Trace, a question I have is when and how it was morphed from aiming to find ~30 contacts per index case, needed to contain spread, into a service that contacts 2-4 contacts per index case, mostly within household.” / Twitter. (n.d.). Retrieved June 28, 2021, from https://twitter.com/ChristoPhraser/status/1408454903249477632

    1. VicGovDH. (2021, June 8). Reported yesterday: 1 new local case, 0 new cases acquired overseas. Got symptoms? Get tested. - 19,533 vaccine doses administered—28,485 test results received More later: Https://t.co/lIUrl0ZEco #COVID19VicData #COVID19Vic https://t.co/wc5BUgm6OK [Tweet]. @VicGovDH. https://twitter.com/VicGovDH/status/1402398048232349698

    1. A lot of projects leveraging CDP appeared since then, including the most well-known one—Puppeteer, a browser automation library for Node.js. What about the Ruby world? Ferrum, a CDP library for Ruby, although being a pretty young one, provides a comparable to Puppeteer experience. And, what’s more important for us, it ships with a companion project called Cuprite—a pure Ruby Capybara driver using CDP.
    2. That’s not the only way of writing end-to-end tests in Rails. For example, you can use Cypress JS framework and IDE. The only reason stopping me from trying this approach is the lack of multiple sessions support, which is required for testing real-time applications (i.e., those with AnyCable 😉).
    3. Thus, by adding system tests, we increase the maintenance costs for development and CI environments and introduce potential points of failures or instability: due to the complex setup, flakiness is the most common problem with end-to-end testing. And most of this flakiness comes from communication with a browser.
    4. For example, Database Cleaner for a long time was a must-have add-on: we couldn’t use transactions to automatically rollback the database state, because each thread used its own connection; we had to use TRUNCATE ... or DELETE FROM ... for each table instead, which is much slower. We solved this problem by using a shared connection in all threads (via the TestProf extension). Rails 5.1 was released with a similar functionality out-of-the-box.
    5. In practice, we usually also need another tool to provide an API to control the browser (e.g., ChromeDriver).
    6. “System tests” is a common naming for automated end-to-end tests in the Rails world. Before Rails adopted this name, we used such variations as feature tests, browser tests
    7. even acceptance tests (though the latter are ideologically different)
    1. This is why for a recent Angular+Rails project we chose to use a testing stack from the backend technology’s ecosystem for e2e testing.
    2. We were not strictly blackbox testing our application. We wanted to simulate a user walking thru specific scenarios in the app which required that we have corresponding data in the database. This helps ensure integration between the frontend and backend was wired up successfully and would give us a foundation for testing critical user flows.
    3. There are times to stretch individually and as a team, but there are also times to take advantage of what you already know.
    4. When it came to testing the whole product, end-to-end, owning both sides gave us not only more options to consider, but also more tools to choose from.
    5. This meant that we owned both sides of the product implementation. For unit testing on the frontend, we stayed with Angular’s suggestion of Jasmine. For unit testing on the backend, we went with rspec-rails. These worked well since unit tests don’t need to cross technology boundaries.
    6. We used testing tools that were in the same ecosystem as our backend technology stack for primrily three reasons: We owned both ends of the stack Team experience Interacting with the database
    1. Mocking is a form of global state like others (including ENV sharing), which will cause difficulties here (more with threads, a bit less with forks).
    1. How to test at the correct level?
    2. As many things in life, deciding what to test at each level of testing is a trade-off:
    3. Unit tests are usually cheap, and you should consider them like the basement of your house
    4. A system test is often better than an integration test that is stubbing a lot of internals.
    5. Only test the happy path, but make sure to add a test case for any regression that couldn’t have been caught at lower levels with better tests (for example, if a regression is found, regression tests should be added at the lowest level possible).
    6. White-box tests at the system level (formerly known as System / Feature tests)
    7. GitLab is transitioning from controller specs to request specs.
    8. These kind of tests ensure that individual parts of the application work well together, without the overhead of the actual app environment (i.e. the browser). These tests should assert at the request/response level: status code, headers, body. They’re useful to test permissions, redirections, what view is rendered etc.
    9. These tests should be isolated as much as possible. For example, model methods that don’t do anything with the database shouldn’t need a DB record. Classes that don’t need database records should use stubs/doubles as much as possible.
    10. Black-box tests at the system level (aka end-to-end or QA tests)
    11. White-box tests at the system level (aka system or feature tests)
    1. Levels
    2. White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of software testing that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing)
    1. A common cause of a large number of created factories is factory cascades, which result when factories create and recreate associations.
    2. Test speed GitLab has a massive test suite that, without parallelization, can take hours to run. It’s important that we make an effort to write tests that are accurate and effective as well as fast.
    3. :js is particularly important to avoid. This must only be used if the feature test requires JavaScript reactivity in the browser. Using a headless browser is much slower than parsing the HTML response from the app.
    4. Use Factory Doctor to find cases where database persistence is not needed in a given test.
    5. :clean_gitlab_redis_cache which provides a clean Redis cache to the examples.
    6. Time returned from a database can differ in precision from time objects in Ruby, so we need flexible tolerances when comparing in specs. We can use be_like_time to compare that times are within one second of each other.
    7. Parameterized tests
    8. This style of testing is used to exercise one piece of code with a comprehensive range of inputs. By specifying the test case once, alongside a table of inputs and the expected output for each, your tests can be made easier to read and more compact.
    1. In Jest we are currently running all tests in JSDOM and not in a browser. This implies that certain scenarios cannot be tested or behave differently than in the real application.
    1. Move it to Jest. This potentially requires extending our jsdom mocked browser environment. Move it to RSpec. This will probably require us changing our perspective to a use-case oriented one. We just want to make sure we have the same value coverage.
    1. We should test for events emitted in response to an action in our component. This is used to verify the correct events are being fired with the correct arguments.
    2. Do not test the internal implementation of the child components:
    3. Test we react correctly to any events emitted from child components:
    4. Test any directive that defines if/how child component is rendered (for example, v-if and v-for).
    5. A rule of thumb is that data should just be data - it is not recommended to observe objects with their own stateful behavior.
    6. Although each method of a Vue component can be tested individually, our goal is to test the output of the render function, which represents the state at all times.
    1. Global mocks introduce magic and technically can reduce test coverage.
    2. Manual mocks are used to mock modules across the entire Jest environment. This is a very powerful testing tool that helps simplify unit testing by mocking out modules which cannot be easily consumed in our test environment.
    3. Jest provides useful matchers like toHaveLength or toBeUndefined to make your tests more readable and to produce more understandable error messages.
    4. targeting what the user actually sees
    5. hen selecting by text it is best to use the byRole query as it helps enforce accessibility best practices.
    6. The most important guideline to give is the following: Write clean unit tests if there is actual value in testing a complex piece of logic in isolation to prevent it from breaking in the future Otherwise, try to write your specs as close to the user’s flow as possible
    7. Another common gotcha is that the specs end up verifying the mock is working. If you are using mocks, the mock should support the test, but not be the target of the test.
    8. Don’t test the library
    9. Testing the hasMetricTypes computed prop would seem like a given here. But to test if the computed property is returning the length of metricTypes, is testing the Vue library itself. There is no value in this, besides it adding to the test suite.
    10. It’s better to test a component in the way the user interacts with it: checking the rendered template.
  9. May 2021
    1. Method 1: We can grab the PDF Versions of Google’s TotT episodes or create our own posters that are more relevant to the company and put them in places where both developers and testers can’t be ignored.Method 2 : We can initiate something called ‘Tip of the day’ Mailing System from Quality Engineering Department.

      Ways to implement Google's Testing on the Toilet concept

    2. They started to write flyers about everything from dependency injection to code coverage and then regularly plaster the bathrooms in all over Google with each episode, almost 500 stalls worldwide.

      Testing on the Toilet (TotT) concept

    3. Dogfooding → Internal adoption of software that is not yet released. The phrase “eating your own dogfood” is meant to convey the idea that if you make a product to sell to someone else, you should be willing to use it yourself to find out if it is any good.

      Dogfooding testing method at Google

    1. Aleta, A., Martín-Corral, D., Pastore y Piontti, A., Ajelli, M., Litvinova, M., Chinazzi, M., Dean, N. E., Halloran, M. E., Longini Jr, I. M., Merler, S., Pentland, A., Vespignani, A., Moro, E., & Moreno, Y. (2020). Modelling the impact of testing, contact tracing and household quarantine on second waves of COVID-19. Nature Human Behaviour, 1–8. https://doi.org/10.1038/s41562-020-0931-9

    1. ReconfigBehSci. (2021, February 18). @ErikAngner I thought I joined the ‘conversation’ at the top- did I miss part of a prior thread? Post I responded to seemed to be the beginning of a thread...ie. ‘regular reminder that...’ [Tweet]. @SciBeh. https://twitter.com/SciBeh/status/1362385973603168257

    1. Jonathan Rothberg 🦋. (2021, March 2). Testing works. I test daily. Insist on HOME testing. @michaelmina_lab @JoeBiden Research suggests B.1.526 needs to be closely watched “for its ability to evade both monoclonal antibody and, to a certain extent, the vaccine-induced antibody,” said Fauci [Tweet]. @JMRothberg. https://twitter.com/JMRothberg/status/1366755339912306688

    1. Testing your designs is also crucial step during this process.
    2. Remember, even the email clients with better HTML and CSS support have their own individual quirks and still require testing to see what’s possible.
    1. Hall, V. J., Foulkes, S., Saei, A., Andrews, N., Oguti, B., Charlett, A., Wellington, E., Stowe, J., Gillson, N., Atti, A., Islam, J., Karagiannis, I., Munro, K., Khawam, J., Chand, M. A., Brown, C. S., Ramsay, M., Lopez-Bernal, J., Hopkins, S., … Heeney, J. L. (2021). COVID-19 vaccine coverage in health-care workers in England and effectiveness of BNT162b2 mRNA vaccine against infection (SIREN): A prospective, multicentre, cohort study. The Lancet, 0(0). https://doi.org/10.1016/S0140-6736(21)00790-X

  10. Apr 2021
    1. let(:warden) do instance_double('Warden::Proxy').tap do |warden| allow(warden).to receive(:authenticate!).with(scope: :user) .and_return(authenticated?) allow(warden).to receive(:user).with(:user).and_return(user) end end let(:user) { instance_double(User) } let(:authenticated?) { true } def simulate_running_with_devise stub_const( 'Rack::MockRequest::DEFAULT_ENV', Rack::MockRequest::DEFAULT_ENV.merge('warden' => warden), ) end
    2. There is no request.env in functional tests because the functional tests are supposed to remain at the controller level.
  11. Mar 2021
    1. There is obvious connections between the flow paths of a use case and its test cases. Deriving functional test cases from a use case through its scenarios (running instances of a use case) is straightforward.
    1. Larremore, D. B., Wilder, B., Lester, E., Shehata, S., Burke, J. M., Hay, J. A., Tambe, M., Mina, M. J., & Parker, R. (2020). Test sensitivity is secondary to frequency and turnaround time for COVID-19 surveillance. MedRxiv, 2020.06.22.20136309. https://doi.org/10.1101/2020.06.22.20136309