299 Matching Annotations
  1. Last 7 days
    1. Methods must be tested both via a Lemon unit test and as a QED demo. The Lemon unit tests are for testing a method in detail whereas the QED demos are for demonstrating usage.
  2. Mar 2020
    1. Standardized test scores improved dramatically. In 2006, only 10% of Noyes' students scored "proficient" or "advanced" in math on the standardized tests required by the federal No Child Left Behind law. Two years later, 58% achieved that level. The school showed similar gains in reading. Because of the remarkable turnaround, the U.S. Department of Education named the school in northeast Washington a National Blue Ribbon School. Noyes was one of 264 public schools nationwide given that award in 2009. Michelle Rhee, then chancellor of D.C. schools, took a special interest in Noyes. She touted the school, which now serves preschoolers through eighth-graders, as an example of how the sweeping changes she championed could transform even the lowest-performing Washington schools. Twice in three years, she rewarded Noyes' staff for boosting scores: In 2008 and again in 2010, each teacher won an $8,000 bonus, and the principal won $10,000. A closer look at Noyes, however, raises questions about its test scores from 2006 to 2010. Its proficiency rates rose at a much faster rate than the average for D.C. schools. Then, in 2010, when scores dipped for most of the district's elementary schools, Noyes' proficiency rates fell further than average.
    1. Atlanta’s rampant test manipulation amplified calls for nationwide education reform. Seven years after the Atlanta Journal-Constitution first reported on testing problems, policymakers have failed to make significant progress toward changing the way students take standardized tests and how teachers interpret those scores. In fact, the problem has worsened, resulting in documented cheating in at least 40 states, since the APS cheating scandal first came to light. “Atlanta is the tip of the iceberg,” says Bob Schaeffer, public education director of FairTest, a nonprofit opposed to current testing standards. “Cheating is a predictable outcome of what happens when public policy puts too much pressure on test scores.” Some experts, including Schaeffer, point to the No Child Left Behind Act of 2001 as a source of today’s testing problems, though others say the woes predated the law. Then-president George W Bush, who signed the measure in January 2002, aimed to boost national academic performance and close the achievement gap between white and minority students. To make that happen, the law relied upon standardized tests designed to hold teachers accountable for classroom improvements. Federal funding hinged on school improvements, as did the future of the lowest-performing schools. But teachers in many urban school districts already faced enormous challenges that fell outside their control – including high poverty, insufficient food access, and unstable family situations. Though high-stakes testing increased student achievement in some schools, the federal mandate turned an already-difficult challenge into a feat some considered insurmountable. The pressure led to problems. Dr Beverly Hall, the former APS superintendent who was praised for turning around student performance, was later accused of orchestrating the cheating operation. During her tenure, Georgia investigators found 178 educators had inflated test scores at 44 elementary and middle schools.
    1. Atlanta public schools. The urban school district has already suffered one of the most devastating standardized-testing scandals of recent years. A state investigation in 2011 found that 178 principals and teachers in the city school district were involved in cheating on standardized tests. Dozens of former employees of the school district have either been fired or have resigned, and 21 educators have pleaded guilty to crimes like obstruction and making false statements.
    1. For automated testing, include the parameter is_test=1 in your tests. That will tell Akismet not to change its behaviour based on those API calls – they will have no training effect. That means your tests will be somewhat repeatable, in the sense that one test won’t influence subsequent calls.
    1. I would like to make an appeal to core developers: all design decisions involving involuntary session creation MUST be made with a great caution. In case of a high-load project, avoiding to create a session for non-authenticated users is a vital strategy with a critical influence on application performance. It doesn't really make a big difference, whether you use a database backend, or Redis, or whatever else; eventually, your load would be high enough, and scaling further would not help anymore, so that either network access to the session backend or its “INSERT” performance would become a bottleneck. In my case, it's an application with 20-25 ms response time under a 20000-30000 RPM load. Having to create a session for an each session-less request would be critical enough to decide not to upgrade Django, or to fork and rewrite the corresponding components.
    1. Creating meticulous tests before exploring the data is a big mistake, and will result in a well-crafted garbage-in, garbage-out pipeline. We need an environment flexible enough to encourage experiments, especially in the initial place.

      Overzealous nature of TDD may discourage from explorable data science

    2. I would use ESLint in full strength, tests for some (especially end-to-end, to make sure a commit does not make project crash), and add continuous integration.

      Advantage of tests

    3. A few takeaways

      Summarising the article:

      • Types and tests save you from stupid mistakes; thesea re gifts for your future self!
      • Use ESLint and configure it to be your strict, but fair, friend.
      • Think of tests as a permanent console.
      • Types: It is not only about checks. It is also about code readability.
      • Testing with each commit makes fewer surprises when merging Pull Requests.
    4. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

      According to the Kernighan's Law, writing code is not as hard as debugging

  3. Feb 2020
    1. I had created a bunch of annotations on: https://loadimpact.com/our-beliefs/ https://hyp.is/bYpY5lKoEeqO_HdxChFU0Q/loadimpact.com/our-beliefs/

      But when I click "Visit annotations in context"

      Hypothesis shows an error:

      Annotation unavailable The current URL links to an annotation, but that annotation cannot be found, or you do not have permission to view it.

      How do I edit my existing annotations for the previous URL and update them to reference the new URL instead?

    1. Performance Benchmarking What it is: Testing a system under certain reproducible conditions Why do it: To establish a baseline which can be tested against regularly to ensure a system’s performance remains constant, or validate improvements as a result of change Answers the question: “How is my app performing, and how does that compare with the past?”
    1. Do Browse like a user wouldTake natural pauses that users would take to consume page contentFocus on the most common use cases, rather than all the possible use casesTake note of pages where forms/logins occur, you will likely need to complete some scripting there
    1. Yes, traditional scenario load tests are naturally in the risk zone of being axed in the name of this-step-is-taking-too-long as load tests need time to ramp-up and execute the user journeys with the simulated traffic to gain enough measurements that can be acted on. This is why we don’t recommend load tests to be run on every commit for scenario type load tests, but rather in the frequency range of “daily” for performance regression type tests. When merging code into a release branch or as a nightly build perhaps, so that you can have your snazzy load test report with your morning coffee before you’ve settled into your zone!
    2. We believe load test scripts should be plain code to get all the benefits of version control, as opposed to say unreadable and tool generated XML.

      Saw another comment lamenting the use of ugly/unreasonable XML files:

      https://github.com/flood-io/ruby-jmeter

      Tired of using the JMeter GUI or looking at hairy XML files?

    3. It is also good practice to make sure that your load testing is functionally correct. Both the performance and functional goals can be codified using thresholds and checks (like asserts).
    1. Load Testing Manifesto Simple testing is better than no testingLoad testing should be goal orientedLoad testing by developersDeveloper experience is super importantLoad test in a pre-production environment
    2. You can use it for running tests with a high load (spike, stress, endurance tests) in pre-production and QA environments.
    1. Devstringx Technologies opened for business in 2014. Today, Devstringx is India’s most recommended IT company for software product development, mobile app development and independent software testing services which headquarter in Noida, India.

      Website and software development square measure the basics part of running a profitable business. In current promoting, the necessity of custom software is rise day by day. Devstringx technologies one in all the most effective custom software development company in Noida, India. Custom software may be used with none long-time investment. They are doing not need constant development to suit company necessities. You'll be able to expend the software at any time. There square measure multiple advantages of custom advantages development like- efficient, measurability, flexible, compatible, customized answer, security.

      Our experienced, energetic and dedicated team of custom software developers and that we provide complete it software services with budget suited to your pockets. Our consultants recognize alright the key parameter of your business and deliver the proper results on time. We provide additional complete software testing services like functional testing services, performance testing services, Api testing services, usability testing services, content testing services, agile testing services, regression testing services, compatibility testing services, automation testing services, web application testing services in India.

      We've a separate team for every field like software developers, software tester, web developer...! Our team invariably able to work and that they commit the leads to future commitment towards your company. We give higher priority to our client's satisfaction. We specialized in providing the most effective automation testing services in Noida, India.

  4. Jan 2020
    1. Yes; everything needed to run the tests are bundled inside the test suite or executable. There's no connections to foreign processes or systems. I.e, no talking to databases or reading files from disk. If necessary, these connection points are faked / mocked.

      Tests running in isolation don't depends on external systems to work.

  5. Dec 2019
    1. No backup regimen would be complete without testing. You should regularly test recovery of random files or entire directory structures to ensure not only that the backups are working, but that the data in the backups can be recovered for use after a disaster. I have seen too many instances where a backup could not be restored for one reason or another and valuable data was lost because the lack of testing prevented discovery of the problem.
    1. Various test runners support using compiled webpack code to drive tests, but may be difficult to integrate with webpack, and Neutrino helps alleviate this
    1. But what you absolutely should do is test your NPM package in its published format. Create some smoke tests that reside in the actual codebase, but are not part of the test suite.
    1. Testing is hard. For most developers, testing is a sad story.
    2. In React, there are different aspects of UI Testing. We categorize them as follows along with their tooling:
    3. Storybook integrates with Jest Snapshot through an add-on called StoryShots. StoryShots adds automatic Jest Snapshot Testing to our codebase by using our existing Storybook stories as the input for Jest Snapshot Testing.
    4. The most common phrase in a Pull Request (PR) is: Please add the tests
  6. Nov 2019
    1. Since the checkbox is rendering an input I would work with it rather than focusing on the image. You could do something like this: const checkbox = getByTestId('checkbox-1234').querySelector('input[type="checkbox"]') expect(checkbox).toHaveProperty('checked', true)
    2. the way Material UI works is it renders a different SVG when the checkbox is clicked, and not changing the attributes or anything on the actual input element. So how do I actually test that the element is checked in line with the react-testing-library philosophy?

      These tags belong to entire page. This quote is just supporting evidence for the tags.

    1. If you're writing a tool for developers, it's a really common case that you want to write a test to ensure that a good error or warning message is logged to the console for the developers using your tool. Before snapshot testing I would always write a silly regex that got the basic gist of what the message should say, but with snapshot testing it's so much easier.
    2. These four things lead to a near total loss in the intended utility of integrated/functional tests: as the code changes make sure nothing is broken.
    3. (After all, it's not like the past snapshot was well understood or carefully expressed authorial intent.) As a result, if a snapshot test fails because some intended behavior disappeared, then there's little stated intention describing it and we'd much rather regenerate the file than spend a lot of time agonizing over how to get the same test green again.
    4. They are generated files, and developers tend to be undisciplined about scrutinizing generated files before committing them, if not at first then definitely over time. Most developers, upon seeing a snapshot test fail, will sooner just nuke the snapshot and record a fresh passing one instead of agonizing over what broke it.
    5. Good tests encode the developer's intention, they don't only lock in the test's behavior without editorialization of what's important and why. Snapshot tests lack (or at least, fail to encourage) expressing the author's intent as to what the code does (much less why)
    1. I very rarely use snapshot testing with react and I certainly wouldn't use it with shallow. That's a recipe for implementation details. The whole snapshot is nothing but implementation details (it's full of component and prop names that change all the time on refactors). It'll fail any time you touch the component and the git diff for the snapshot will look almost identical to the one for your changes to the component.This will make people careless about to the snapshot updates because they change all the time. So it's basically worthless (almost worse than no tests because it makes you think you're covered when you're not and you won't write proper tests because they're in place).
    2. I should also add that I'm in favor of relying more heavily on integration testing. When you do this, you need to unit test fewer of your simple components and wind up only having to unit test edge cases for components (which can mock all they want).
    3. But isn't the point of testing to be confident the application works? Who cares if your unit works if the app is broken? I definitely want to know if the third party component I'm using breaks my use case. I mean, I'm not going to rewrite their entire test base, but if I can easily test my use case by not mocking out their component then why not do that and get the extra confidence?
    4. it doesn't even render in-file components. For example, the <Fade /> component we have above is an implementation detail of the <HiddenMessage /> component, but because we're shallow rendering <Fade /> isn't rendered so changes to that component could break our application but not our test. That's a major issue in my mind and is evidence to me that we're testing implementation details.
    5. The reason this kind of test fails those considerations is because it's testing irrelevant implementation details. The user doesn't care one bit what things are called. In fact, that test doesn't even verify that the message is hidden properly when the show state is false or shown when the show state is true. So not only does the test not do a great job keeping us safe from breakages, it's also flakey and doesn't actually test the reason the component exists in the first place.
    6. I could rename toggle to handleButtonClick (and update the corresponding onClick reference). My test breaks despite this being a refactor.
    7. I could mistakenly set onClick of the button to this.tgogle instead of this.toggle. My test continues to work, but my component is broken.
    8. let's add a console.log(wrapper.debug()) which will log out the structure of what enzyme has rendered for us
    9. Will this test break when there's a mistake that would break the component in production?Will this test continue to work when there's a fully backward compatible refactor of the component?
    10. So finally I'm coming out with it and explaining why I never use shallow rendering and why I think nobody else should either. Here's my main assertion:With shallow rendering, I can refactor my component's implementation and my tests break. With shallow rendering, I can break my application and my tests say everything's still working.This is highly concerning to me because not only does it make testing frustrating, but it also lulls you into a false sense of security. The reason I write tests is to be confident that my application works and there are far better ways to do that than shallow rendering.
    1. Tests implementation details a bit (child component props received), but pretty good other than that.

      https://www.robinwieruch.de/react-testing-tutorial, for example, says that is reasonable to do:

      an integration test could verify that all necessary props are passed through from the tested component to a specific child component.

    1. Often, if you are writing a test that amounts to “it does what it does”, or “it does exactly this, which happens to be duplicated in the application code”, then the test is either unnecessary or too broad.
    2. Here are three rules of thumb I use to determine that something is not worth testing:Will the test have to duplicate exactly the application code? This will make it brittle.Will making assertions in the test duplicate any behavior that is already covered by (and the responsibility of) library code?From an outsider’s perspective, is this detail important, or is it only an internal concern? Can the effect of this internal detail be described using only the component’s public API?
    1. Yes, we've violated that "one assertion per test" rule, but that rule was originally created because testing frameworks did a poor job of giving you the contextual information you needed to determine what was causing your test failures.

      So that's why we had the "one assertion per test" rule. I first heard about that back when I was writing rspec tests. Now rspec has :aggregate_failures option, which makes it easier to write multiple assertion per test.

    1. When you mock something, you're making a trade-off. You're trading confidence for something else. For me, that something else is usually practicality — meaning I wouldn't be able to test this thing at all, or it may be pretty difficult/messy, without mocking. (Like in our credit card example.)
    1. You’ll rest easy at night, knowing that the proper amount of automated test coverage is in place and protecting your product from unintentional breakage.
    1. But far too often, I see tests which are testing implementation details (read this before continuing if you haven't already). When you do this, you introduce a third user. The developer user and the end user are really all that matters for this component. So long as it serves those two, then it has a reason to exist. And when you're maintaining the component you need to keep those two users in mind to make sure that if you break the contract with them, you do something to handle that change.But as soon as you start testing things which your developer user and end user don't know or care about (implementation details), you add a third testing user, you're now having to keep that third user in your head and make sure you account for changes that affect the testing user as well.
    2. "The more your tests resemble the way your software is used, the more confidence they can give you. "
    1. Why is testing implementation details bad?There are two distinct reasons that it's important to avoid testing implementation details. Tests which test implementation details:Can break when you refactor application code. False negativesMay not fail when you break application code. False positives
    1. You want to write maintainable tests for your React components. As a part of this goal, you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. As part of this, you want your testbase to be maintainable in the long run so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.
    2. This library is a replacement for Enzyme.
    1. The more your tests resemble the way your software is used, the more confidence they can give you.
    2. Most of the damaging features have to do with encouraging testing implementation details. Primarily, these are shallow rendering, APIs which allow selecting rendered elements by component constructors, and APIs which allow you to get and interact with component instances (and their state/properties) (most of enzyme's wrapper APIs allow this).
    1. “Code without tests is broken by design”
    2. Here are my tools of choice for testing React apps:react-test-renderer for snapshot unit testingAct API for unit testing React componentsJest for unit and integration testing of JavaScript codeCypress for end to end / ui testing
    3. In Double-loop TDD it’s functional testing that drives our development. We write a functional test for testing that our application satisfy some user stories. When the functional test fails we move to write unit and integration tests which in turn drive how we code our components.
    1. I don't recommend unit testing stateful components, or components with side-effects. Write functional tests for those, instead, because you'll need tests which describe the complete end-to-end flow, from user input, to back-end-services, and back to the UI. Those tests frequently duplicate any testing effort you would spend unit-testing stateful UI behaviors. You'd need to do a lot of mocking to properly unit test those kinds of components anyway, and that mocking may cover up problems with too much coupling in your component.
    1. The amount of dev time it saves is uncanny. Like, what used to take 3 hours to write now takes like 30 minutes. No joke.
    2. If you’re dedicated to reducing flakiness, you can take this a step further and reduce flake in your tests even more by killing timers that are set in your tests:
    1. Snapshot testing is great as it let us capture strings that represent our rendered components and the store it in a separate snapshot file to compare later in order to ensure that UI is not change. While it is ideal for React apps, we can use snapshots for comparing values that are serialized from other frameworks.
    2. Screenshot Test: Applications are not often screenshot tested. However, if the business requirement is there, screenshot tests can be used to diff two screenshots from the same application state in order to verify whether something (styling, layout, …) has changed. It’s similar to a snapshot test, whereas the snapshot test only diffs the DOM and the screenshot test diffs screenshots.
    3. Snapshot Test: Introduced by Facebook’s library Jest, Snapshot Tests should be the lightweight variation of testing (React) components. It should be possible to create a DOM snapshot of a component once a test for it runs for the first time and compare this snapshot to a future snapshot, when the test runs again, to make sure that nothing has changed. If something has changed, the developer has to either accept the new snapshot test (the developer is okay with the changes) or deny them and fix the component instead.
    1. Author Mary Burns discusses the key elements of computer adaptive testing (CAT). CAT is defined as assessments that use algorithms to progressively adjust test difficulty based upon learner's correct or incorrect responses. The benefits of CAT include more immediate data and are often more reliable. Types of test items are also covered to illustrate how the test can meet various levels of cognition and measure expertise. An issue related to CAT is the intensive time needed to develop multiple test items at multiple levels of cognition. Rating: 8/10

  7. Oct 2019
  8. Sep 2019
    1. The issue that had roiled the grown-ups in his life seemed to have had no effect on him at all.

      I wonder if that suggests the tests matter less, or more?

    2. A 95 percent opt-out rate was a resounding success. It rivaled election results in Turkmenistan.

      Wow. That's an incredibly long reach to make an incendiary point.

  9. Aug 2019
    1. been set. This

      Acknowledging an opposing argument (i.e. a 'counterargument'), and then showing why that counter argument is invalid is an excellent strategy when arguing a point. Using a counter argument will help position you as a more sophisticated and accomplished writer. See the following for more help: https://11trees.com/guide/strengthen-your-argument-by-including-a-counterargument/.

  10. Jul 2019
    1. his, too, is false. Indeed, the data from released national tests show conclusively that the students have the most difficulty with those items that require understanding and transfer, not recall or recognition.

      interesting...maybe this goes to show that educators as a whole are focusing more on rote memorization and not true application of learning

    2. This perceived incompatibility is based on a flawed assumption that the only way to raise test scores is to cover those things that are tested and practice the test format.

      But is there any real way to get around this?

  11. May 2019
  12. Apr 2019
    1. excess toxicities withparticular cytotoxic therapies

      indication for genetic testing

    Tags

    Annotators

    1. Ashley Norris is the Chief Academic Officer at ProctorU, an organization that provides online exam proctoring for schools. This article has an interesting overview of the negative side of technology advancements and what that has meant for student's ability to cheat. While the article does culminate as an ad, of sorts, for ProctorU, it is an interesting read and sparks thoughts on ProctorU's use of both human monitors for testing but also their integration of Artificial Intelligence into the process.

      Rating: 9/10.

  13. Mar 2019
    1. Particle-Based Approximate Inference

      This is just a testing and nothing more. $$a^2 + b^2 = c^2$$

    Tags

    Annotators

    1. quick and dirty usability testing

      This page has an irritating pop-up ad as well as quite a bit of images that surround the text. Nonetheless, it offers tips and techniques for making sure that usability testing gets done at some level and can be done by the average person who may not have time, money, or a lab. Rating 2/5

    1. A field study at Google[4] covering over 100,000 consumer-grade drives from December 2005 to August 2006 found correlations between certain S.M.A.R.T. information and annualized failure rates: In the 60 days following the first uncorrectable error on a drive (S.M.A.R.T. attribute 0xC6 or 198) detected as a result of an offline scan, the drive was, on average, 39 times more likely to fail than a similar drive for which no such error occurred. First errors in reallocations, offline reallocations (S.M.A.R.T. attributes 0xC4 and 0x05 or 196 and 5) and probational counts (S.M.A.R.T. attribute 0xC5 or 197) were also strongly correlated to higher probabilities of failure. Conversely, little correlation was found for increased temperature and no correlation for usage level. However, the research showed that a large proportion (56%) of the failed drives failed without recording any count in the "four strong S.M.A.R.T. warnings" identified as scan errors, reallocation count, offline reallocation and probational count. Further, 36% of failed drives did so without recording any S.M.A.R.T. error at all, except the temperature, meaning that S.M.A.R.T. data alone was of limited usefulness in anticipating failures.[5]
  14. Feb 2019
    1. Students require a variety of learning situations and opportunities in order to be aware of and reflect on...variation, and to be able to make fine distinctions about the significant aspects of each new context. By identifying the differences between similar situations, the student is better able to respond appropriately. Such learning experiences are an important preparation for the unpredictable nature of the workplace

      Special Requirements

    Tags

    Annotators

  15. Jan 2019
    1. A village scoring 1.5 and another scoring 1.49 would be almost equally insecure.

      This reminds me of an anecdote from Vietnam. A platoon was ordered to repeatedly bomb an empty village when the correct village was nearby.

  16. Dec 2018
    1. Then inject it inside a test by calling TestBed.get() with the service class as the argument. it('should use ValueService', () => { service = TestBed.get(ValueService); expect(service.getValue()).toBe('real value'); });

      this is for testing the service, directly

    2. However, you almost always inject service into application classes using Angular dependency injection and you should have tests that reflect that usage pattern. Angular testing utilities make it easy to investigate how injected services behave.

      key point