- Aug 2024
-
github.com github.com
-
This is the most simulative version of a controller. It will try and mimic real user behaviour. It's the recommended version to use when the goal of the load-test is finding out how many concurrently active users the target instance supports.
-
- May 2024
-
-
As of right now the full build takes over an hour to run, and this makes cycling for PRs and quick iterative development very difficult.
-
- Dec 2023
-
developers.secure.facebook.com developers.secure.facebook.com
- Nov 2022
-
www.destroyallsoftware.com www.destroyallsoftware.com
-
Video on Functional Core, Imperative Shell paradigm. Recommended in Hypothes.is testing documentation
-
-
h.readthedocs.io h.readthedocs.io
-
the functional core, imperative shell pattern
Link to video on "Boundaries" doesn't go into depth on the functional core, imperative shell pattern. However, this one does: https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell
-
For new code, it’s usually a good idea to design the code so that it’s easy to test with “real” objects, rather than stubs or mocks.
-
We keep our functional tests separate from our unit tests, in the tests/functional directory. Because these are slow to run, we will usually write one or two functional tests to check a new feature works in the common case, and unit tests for all the other cases.
Keep functional & unit tests separate. Functional for common cases, unit for all others.
-
To run the backend test suite only call tox directly
Probably means, "Call
tox
directly if you only want to run the backend test suite."
-
- Jun 2022
-
en.itpedia.nl en.itpedia.nl
-
Black Box testing: Software on the rack
Black Box testing: Software on the rack
Black Box testing is defined as a testing technique in which the functionality of an application is tested without looking at the internal code structure, implementation details and knowledge of internal paths of the software. This type of testing is completely based on software requirements and specifications.
-
-
en.itpedia.nl en.itpedia.nl
-
It is important that you achieve optimal test results with software testing without deviating from the test goal. But how do you determine whether you are following the right test strategy? For this you have to follow a number of basic principles.
-
- Mar 2022
-
en.itpedia.nl en.itpedia.nl
-
A test case is a series of actions that are performed to determine a specific function or functionality of your application. Test scenarios are rather vague and include a wide range of variables. However, testing is all about being very specific. That is why we need elaborate test cases.
Test cases, examples and Best Practices A test case is a series of actions that are performed to determine a specific function or functionality of your application. Test scenarios are rather vague and include a wide range of variables. However, testing is all about being very specific. That is why we need elaborate test cases.
-
- Feb 2022
-
-
STLC - Software Testing Life Cycle
Software Testing Life Cycle (STLC) is defined as a set of activities performed to perform software testing. The Software Testing Life Cycle refers to a testing process with specific steps that must be performed in a specific order to ensure that quality objectives are met.
-
- Nov 2021
-
www.varvet.com www.varvet.com
-
I am firmly convinced that asserting on the state of the interface is in every way superior to asserting on the state of your model objects in a full-stack test.
-
- Sep 2021
-
www.npmjs.com www.npmjs.com
-
The more your tests resemble the way your software is used, the more confidence they can give you.
-
- Jun 2021
-
www.mutuallyhuman.com www.mutuallyhuman.com
-
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.
-
There are times to stretch individually and as a team, but there are also times to take advantage of what you already know.
Tags
- software stack: choosing
- key point
- testing: end-to-end
- software stack: choosing: factors: familiarity/experience
- people stick to what they know
- good advice
- testing: stack: choosing
- testing: stack
- using disparate technologies in a single project
- how to choose a dependency/library/framework
Annotators
URL
-
-
docs.gitlab.com docs.gitlab.com
-
targeting what the user actually sees
-
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
-
It’s better to test a component in the way the user interacts with it: checking the rendered template.
-
- Mar 2021
-
trailblazer.to trailblazer.to
-
There’s no need to test controllers, models, service objects, etc. in isolation
-
Run the complete unit with a certain input set, and test the side-effects. This differs to the Rails Way™ testing style, where smaller units of code, such as a specific validation or a callback, are tested in complete isolation. While that might look tempting and clean, it will create a test environment that is not identical to what happens in production.
Tags
- testing: philosohy of testing
- rails: the Rails way
- testing: avoid testing implementation details
- testing: avoid unnecessarily testing things in too much isolation, in a different way than the code is actually used (should match production)
- the Trailblazer way
- testing: tests should resemble the way your software is used
- unnecessary
- isolation (programming)
Annotators
URL
-
- Feb 2021
-
-
Excel: Why using Microsoft’s tool caused Covid-19 results to be lost. (2020, October 5). BBC News. https://www.bbc.com/news/technology-54423988
-
- Nov 2020
-
blogs.oracle.com blogs.oracle.com
-
kentbeck,
-
- Oct 2020
-
stackoverflow.com stackoverflow.com
-
Library author here. I'm always fascinated by new ways people can invalidate my assumptions. I mean that in a sincerely positive way, as it results in learning.
Tags
- sincere
- they've thought of everything
- can't support everything / all cases
- invalidating one's assumptions
- learning from others
- assumptions
- surprising
- author of software answering questions in community (support)
- not:
- testing/challenging one's assumptions (either validating or invalidating them)
- not considering all use cases
- different way of thinking about something
Annotators
URL
-
- Jun 2020
-
twitter.com twitter.com
-
Nivi Mani on Twitter. "I cannot stop smiling! Here is a first peek at the data from our online browser-based intermodal preferential looking set-up! We replicate the prediction effect (boy eats big cake, Mani & Huettig, 2012) using our online webcam testing software @julien__mayor @Kindskoepfe_Lab" / Twitter. (n.d.). Twitter. Retrieved June 15, 2020, from https://twitter.com/nivedita_mani/status/1265556217486815232
-
-
psyarxiv.com psyarxiv.com
-
Han, H., & Dawson, K. J. (2020). JASP (Software) [Preprint]. PsyArXiv. https://doi.org/10.31234/osf.io/67dcb
-
- May 2020
-
sciencebusiness.net sciencebusiness.net
-
What’s the COVID-19 re-entry plan? Experts debate Europe’s tricky road ahead. (n.d.). Science|Business. Retrieved April 20, 2020, from https://sciencebusiness.net/news/whats-covid-19-re-entry-plan-experts-debate-europes-tricky-road-ahead
-
-
percy.io percy.io
- Apr 2020
-
xunitpatterns.com xunitpatterns.com
- Feb 2020
-
about.gitlab.com about.gitlab.com
-
development is hard because you have to preserve the ability to quickly improve the product in the future
-
-
loadimpact.com loadimpact.com
-
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).
-
-
www.devstringx.com www.devstringx.com
-
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.
-
- Nov 2019
-
kentcdodds.com kentcdodds.com
-
"The more your tests resemble the way your software is used, the more confidence they can give you. "
-
-
testing-library.com testing-library.com
-
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.
-
We try to only expose methods and utilities that encourage you to write tests that closely resemble how your web pages are used.
-
The more your tests resemble the way your software is used, the more confidence they can give you.
-
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).
-
This library is a replacement for Enzyme.
Tags
- testing: philosohy of testing
- javascript: testing: react-testing-library
- confidence
- replacement for:
- javascript: testing: enzyme
- testing: integration tests
- testing
- competition in open-source software
- testing: mocking
- quotable
- testing: avoid testing implementation details
- testing: tests should resemble the way your software is used
Annotators
URL
-
-
www.valentinog.com www.valentinog.com
-
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
-
-
testingjavascript.com testingjavascript.com
- Nov 2018
-
www.reddit.com www.reddit.com
-
Something that I've found helps greatly with testing is that when you have code with lots of nested function calls you should try to refactor it into a flat, top level pipeline rather than a calling each function from inside its parent function. Luckily in clojure this is really easy to do with macros like -> and friends, and once you start embracing this approach you can enter a whole new world of transducers. What I mean by a top level pipeline is that for example instead of writing code like this: (defn remap-keys [data] ...some logic...) (defn process-data [data] (remap-keys (flatten data))) (defn get-data [] (let [data (http/get *url*)] (process-data data))) you should make each step its own pure function which receives and returns data, and join them all together at the top with a threading macro: (defn fetch-data [url] (http/get url)) (defn process-data [data] (flatten data)) (defn remap-keys [data] ...some logic...) (defn get-data [] (-> *url* fetch-data process-data remap-keys)) You code hasn't really changed, but now each function can be tested completely independently of the others, because each one is a pure data transform with no internal calls to any of your other functions. You can use the repl to run each step one at a time and in doing so also capture some mock data to use for your tests! Additionally you could make an e2e tests pipeline which runs the same code as get-data but just starts with a different URL, however I would not advise doing this in most cases, and prefer to pass it as a parameter (or at least dynamic var) when feasible.
testing flat no deep call stacks, use pipelines
-
- Nov 2016
-
misko.hevery.com misko.hevery.com
-
You shouldn’t really be doing this anyway – you should have composed them, possibly via IOC.
Anybody can explain some more his idea?
-