首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

NgRx效果:单元测试-似乎操作永远不会产生效果

NgRx是一个用于构建响应式应用程序的状态管理库,它基于Redux模式。NgRx提供了一种在Angular应用程序中管理状态的方式,通过将应用程序的状态存储在一个单一的可预测的状态树中,并使用纯函数来处理状态的变化。

在NgRx中,效果(Effect)是一种用于处理副作用的机制。副作用是指与应用程序状态无关的操作,例如异步请求、访问浏览器缓存或本地存储、与服务器通信等。效果允许我们在响应状态变化时执行这些副作用。

对于NgRx效果的单元测试,我们可以采取以下步骤:

  1. 创建一个测试套件,并导入所需的测试工具和依赖项。
  2. 创建一个测试用例,并在该测试用例中创建一个效果实例。
  3. 设置测试用例的初始状态和预期结果。
  4. 使用测试工具模拟应用程序状态的变化,例如发出一个动作。
  5. 使用测试工具调度效果,并等待效果的执行。
  6. 使用断言来验证预期结果是否与实际结果匹配。

以下是一个示例测试用例:

代码语言:txt
复制
import { TestBed } from '@angular/core/testing';
import { provideMockActions } from '@ngrx/effects/testing';
import { Observable, of } from 'rxjs';
import { TestScheduler } from 'rxjs/testing';

import { MyEffect } from './my.effect';
import { MyService } from './my.service';
import { MyAction, MySuccessAction } from './my.actions';

describe('MyEffect', () => {
  let effect: MyEffect;
  let actions$: Observable<any>;
  let myService: jasmine.SpyObj<MyService>;
  let scheduler: TestScheduler;

  beforeEach(() => {
    const spy = jasmine.createSpyObj('MyService', ['getData']);
    TestBed.configureTestingModule({
      providers: [
        MyEffect,
        provideMockActions(() => actions$),
        { provide: MyService, useValue: spy }
      ]
    });
    effect = TestBed.inject(MyEffect);
    actions$ = TestBed.inject(Actions);
    myService = TestBed.inject(MyService) as jasmine.SpyObj<MyService>;
    scheduler = new TestScheduler((actual, expected) => {
      expect(actual).toEqual(expected);
    });
  });

  it('should dispatch MySuccessAction on successful data retrieval', () => {
    const data = { id: 1, name: 'Test' };
    const action = new MyAction();
    const completion = new MySuccessAction(data);

    scheduler.run(({ hot, cold, expectObservable }) => {
      actions$ = hot('-a', { a: action });
      myService.getData.and.returnValue(of(data));

      expectObservable(effect.myEffect$).toBe('--b', { b: completion });
    });
  });
});

在这个示例中,我们创建了一个测试套件,并使用provideMockActions提供了一个模拟的actions$流。我们还创建了一个MyService的模拟对象,并使用jasmine.createSpyObj创建了一个myService的间谍对象。

在测试用例中,我们设置了一个初始动作MyAction和预期的结果MySuccessAction。然后,我们使用TestScheduler来模拟时间的流逝,并使用expectObservable来验证预期结果。

这只是一个简单的示例,你可以根据实际情况扩展和修改测试用例。对于NgRx效果的单元测试,你可以使用类似的方法来测试其他副作用,例如处理错误、调度其他动作等。

关于NgRx效果的更多信息,你可以参考腾讯云相关产品和产品介绍链接地址。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

Angular 接入 NGRX 状态管理

UpdateUser: emptyProps(), }, }); 完成副作用编写: 在 UserEffects 中注入 UserService 后开始创建副作用,总共 4 步操作: import {...UserActions.updateUser()); }, 5000); } } PS:以上案例完整代码可访问 github.com/OSpoon/angu… 接入实体 实体的引入对应单个用户状态的管理来说起到的效果并不明显...todo.model.ts、todo.reducer.ts ,同时也更新了 app/store/index.ts: 接入实体的代码在 todo.reducer.ts 文件中体现,下面是接入实体的核心部分,更多的适配器操作可以看文件中默认生成的模板代码...创建后续对象操作的适配器 export const adapter: EntityAdapter = createEntityAdapter(); // 3....this.store.select(selectTotal); } ... } 小结:通过接入实体,可以使用其内置的适配器对 Todo 进行添加、更新、删除、批量添加、批量更新、批量删除、清空等操作

21510

一个Angular 5教程:一步一步指导实现你的第一个Angular 5应用程序

因此,“对结果的评估不会导致任何语义上可观察到的副作用或输出,例如可变对象的突变或输出到I / O设备”......我们能做什么?答案在这个定义中是正确的。Ngrx对救援的副作用。...,Actions并通过使用ofType 操作符来仅过滤必要的操作。...你可以使用ofType来创建一个会在多种动作类型上触发的效果。但就目前而言,我们在三项行动中只需要两项。对于该Load操作,我们正在将每个操作转换为getCardList方法调用结果的新可观察对象。...所以我们不需要自己添加该卡,或者我们需要take(1)在该管道中使用操作员。它将采取一个单一的价值,并取消订阅。但是实时订阅似乎更合理(假设系统中有多个用户),所以让我们更改我们的代码以处理订阅。...RxJS是JavaScript的Reactive Extensions库,允许我们使用Observables进行操作,Observables是替代我们独立承诺的事件流。 什么是NgRX

42.6K10

昂贵的质量——为什么bug总在发生?

但我们似乎都不愿承认的一个事实是: bug是代码的副产品而已。 如果我们选择接受编码不过是人思维活动的一种形式,与思考无异,那我们也就必须接纳,人性的缺陷在代码中自然也不会缺席,恰如硬币的正反两面。...因为人们既不会因为没有 bug而选择长时间地使用一款应用,也不会因为存在 bug而成为转投它竞争对手的唯一理由。...我们必须承认这样一个事实:质量永远也不是商业的核心竞争力,这也暗示着: 有些功能缺陷是可以被容忍的 质量被分配得到的资源永远是有限的。...原谅我用一个粗俗的比喻来解释为什么这么做行不通: 我们换来的只是打扫的速度,对制造垃圾的人产生不了任何影响,效果甚至会适得其反:考虑到总有人为他们收拾残局,我们的善后工作做得越好,他们越是会肆无忌惮。...我们不妨就以单元测试为例,看看我们需要付出多大的成本 首先,时间便是一笔可观的支出。以我所在的项目为例,我们为前端React 组件编写单元测试的时间,几乎与开发功能的时间相同。

8710

Angular vs React 最全面深入对比

RxJS RxJS是一个响应式编程库,可以灵活地处理异步操作和事件。它是将Observer和Iterator模式与功能编程相结合的组合。...要掌握它,您将需要了解不同类型的“可观察”,“主题”以及大约一百种方法和操作符 。 当您使用连续数据流(如Web套接字)工作很多的情况下,RxJS非常有用,但是对于其他任何东西来说似乎过于复杂。...@ngrx/store @ngrx/store是由Redux启发的Angular的状态管理库,基于由pure reducer进行突变的状态。...Jest(来自Facebook的一个单元测试工具)也同时集成在Create-react-app内部,更方便的让我们进行单元测试。...Demo通常不会(也不应该)花费很多时间,但会提供一些宝贵的经验,可以帮助您验证关键的技术要求。如果对结果感到满意,可以继续全面构建。如果没有,会给你充分的时间重新选择。

3.8K70

写在 2021: 值得关注学习的前端框架和工具库

对于我认为较为主流的则不会包含(如Vue与React框架本身这种~)。...ApolloGraphQL[36]的作品,只有React版本是官方团队在维护,Vue版本的被挪到Vue团队了(VueUI有一部分就是基于Apollo-Client-Vue[37]写的),Angular版本[38]的似乎是个人作品...实际上是一个“理念”,在各个语言都有相关的实现,如RxDart[87]RxJava[88] RxPy[89] RxGo[90] 等等,在对于异步的处理上是非常有帮助的一个库,但有一定的学习成本,比如海量的操作符与操作符组合...秉承了Angular的思想,提供了一整套的集成:和Angular Router的集成:@ngrx/router-store;对于集合类型的适配:@ngrx/entity;副作用管理:@ngrx/effects...E2E测试:Cypress[94] / PlayWright[95],说实话很少能看到业务项目有完备的单元测试和集成测试,更不要说E2E测试了,因为的确要花不少时间。

4.2K10

DevOps落地-让我们从CICD开始~

一开始可以以单元测试入手,随着时间扩展覆盖面。 单元测试:范围非常小,验证每个独立方法级别的操作。 集成测试:保证模块间运行正常,包括多个模块、多个服务。...单元测试前期投入少,短期内可以看到效果,对开发人员要求高;UI测试前期人员成本投入大,需要很长时间看到效果 参考:Shift Left to Make Testing Fast and Reliable...代码覆盖工具将帮助您找到未经测试的代码,但在一天结束的时候,测试的质量会产生影响。...这将为您提供一个安全网,以确保在重构代码或添加新功能后,原始行为不会受到影响。 5. 测试/部署环境准备 测试需要多少资源 ? 如何初始化资源?私有 or 公有云? 编写自动化部署脚本?...似乎编写测试用例拖慢了项目节奏,但是它可以减少回归时间,减少每次迭代带来的 bug。而且每次测试通过后,将会非常有信息合并到主干分支,因为新增的内容不影响以前的功能。 修 bug 的时候编写测试用例。

17310

为什么需要前端自动化测试呢?

而接入前端自动化测试,可以帮助我们提前暴露bug并修复、降低bug产生的成本/提升测试的覆盖率,降低对其他功能原有逻辑的干扰。...,不同功能集成在一起,验证整体功能 ui测试 并不是只对ui设计效果的验证,而是只对数据渲染、交互上的验证 端对端测试 相对真实、完整链路的模拟真实操作验证 在vue或react这种前端框架下,延伸出一种组件测试...这种模式成为测试驱动开发(TDD) 很简单的道理,如果你写的代码逻辑有问题,那么按照错误逻辑写的单元测试永远不可能验证出问题来。...渲染组件/执行条件/准备数据 行动(Act) 对系统执行操作,例如点击按钮、触发钩子函数 断言(Assert) 确保真实的结果匹配你的期望 单元测试开发案例 假设现在我们要开发一个按钮, 我们先来设计这个按钮的功能...要考虑验证的的内容是否有价值需要自动化测试,我们费劲心血写的自动化测试是否足够稳健,不会频繁变更。 总之只有合适的才是最好的。

1.3K30

写在2021: 值得关注学习的前端框架和工具库

对于我认为较为主流的则不会包含(如Vue与React框架本身这种~)。...Apollo-Client,来自ApolloGraphQL的作品,只有React版本是官方团队在维护,Vue版本的被挪到Vue团队了(VueUI有一部分就是基于Apollo-Client-Vue写的),Angular版本的似乎是个人作品...秉承了Angular的思想,提供了一整套的集成:和Angular Router的集成:@ngrx/router-store;对于集合类型的适配:@ngrx/entity;副作用管理:@ngrx/effects...,以及必不可少的schematics:@ngrx/schematics等,最大的优势是和RxJS的深度集成。...E2E测试:Cypress / PlayWright,说实话很少能看到业务项目有完备的单元测试和集成测试,更不要说E2E测试了,因为的确要花不少时间。

2.8K10

对于iOS程序员如何去进阶,为什么很多人都判断错了

3、你是在学习技术,而不是在学如何使用工具,重点关注编程基础,因为基础永远不会改变;更关注体系结构而不是如何编程。...核心动画 从官方文档着手分析核心动画底层原理.了解仿射变换底层原理.以及粒子效果的实现. 1: 核心动画中仿射变换(*****) 2: OpenGL 中模型视图变换(***) 3: 3D数学-...(****) 6: 粒子效果底层原理,使用OpenGL ES 实现粒子效果(*****) 单元测试 系统的单元测试息息相关,它能帮助开发人员,节省时间(尤其回归测试)辅助项目架构,降低耦合度!...单元测试代码非常简单,但是思维确实很多开发者所欠缺的。...总而言之,单元测试时一位iOS中高级开发人员必备技能 1:单元测试是什么 (***) 2:逻辑测试(****) 3:性能测试(*****) 4:异步测试(*****) 5:UI测试(****)

22520

调试 RxJS 第2部分: 日志篇

rxjs-spy 对使用 tag 操作符标记过的 observables 起作用,tag 操作符使用字符串标签名来注释 observable,仅此而已。...当编写 redux-observable 的 epics 或 ngrx 的 effects 时,我见过一些开发者的代码大概是这样的: ? 乍看上去没什么问题,而且大多数情况下也能正常运行。...这种 bug 还是在单元测试里发现不了的。 问题就是有时候 epic 就会停止运行。再具体一点就是当 dispatch 了报错的 action 后它会停止运行。 日志显示了具体发生了什么: ?...catch 操作符的文档解释了这一现象发生的原因: 无论 selector 函数返回的 observable 是什么,都会被用来继续执行 observable 链。...这样 epic 便不会完成,它会继续 dispatch 报错的 actions: ? 在这两个示例中,对于被调试的代码来说,唯一需要修改就是是添加了某个标记注释。

1.2K40

微服务产品级敏捷: 重新定义软件需求分析

然而,遗憾的是,即使研发团队搬出再伟大、再新潮的敏捷或软件工程的实践,似乎也抵挡不住来自市场、产品管理团队的海量需求、压力?...为何研发团队越专业的与市场、产品管理团队谈需求价值、排序,却往往换来的是更大的反效果?...唯一且根本的原因是:研发团队往往都并没有学会,如何与市场、产品管理团队产生 “综效”⋯ 如何将自己当成市场、产品管理团队去深度思考:自身应该先能为市场、产品管理团队做些什么?...假如,研发团队没具备这样的 “综效” 思维;永远都只是看到自己,永远都看不到市场、产品管理团队,那市场、产品管理团队,也绝对是用同样的思维,对待我们。...总之,研发团队假如情商够高的话,就应该不会在市场、产品管理团队的面前,说某某需求没价值。因为,这样的说法真的是很伤人的;而伤人一万,往往是自损三千。

680100

这些必备的VSCode JavaScript插件你都用过吗?

有很多满足此条件的VS Code插件,当然我不会都作介绍。相反,我会着重介绍那些已经相当流行而且对前端开发者来说必不可少的VS Code插件。为简单起见,我把它们分为10类。...拥有需要代码操作,比如把var转为const或者let,去除多余的else语句,合并声明和初始化。其灵感大量源于WebStorm的启发。...这意味着,你会频繁地刷新浏览器以观察每次你更新代码的效果。这里有一些工具,能极大地减少你开发时的这种重复流程,而不是每次都手动刷新浏览器: 1....Angular 6(提供Angular 6的代码片段,支持TypeScript、HTML、Angular Material ngRx、RxJS和Flex Layout。...你可以通过阅读我们的指南-JavaScript测试:单元测试 vs 功能测试 vs 集成测试-来获得对JavaScript测试的一个概观。

5.8K10

关于ARkit

但是在第一时间更新到ios11,并体验了AR游戏应用后,很容易产生一种,『哇,这就是未来的感觉』 但是实际上冷静下来以后,就会发现其实大部分AR应用只是在以往的『图像识别』的基础上,进行『无图像识别』的操作...这样的效果,就算说是基于他们所处于的平面上的一张图片进行识别的效果,又有谁会觉得奇怪呢? 当然,在技术上这是重大的突破,在体验上,makerless也比makerbase强上太多。...相对而言,我更喜欢ARkit所展示出来的另一个效果:『空间检测』。 ? 不过缺少了酷炫的模型,这个逆天的能力反而没有太让人产生惊艳的感觉。 其他的AR效果就不贴图了。...这些东西的『变现能力』现阶段还远没有达到商人预期,但是,这却是人类一直在追求的东西,永远不可能停息。 驱动人类科技的,永远是人类的想象。...不过似乎有了android后就安分多了。 web端有着得天独厚的『随时随地』打开的优势,其他方面还落后世界版本很多进度。但是抱紧google大佬的大腿应该不会有什么错。 ---- 下次推送小故事。

78980

单元测试两三问

单元测试是一种设计行为 使用TDD测试驱动,编写单元测试将验收点实现的过程,使我们从调用者角度进行观察和思考,可以将程序往易调用、可测试的方向设计,降低代码的耦合度,减少测试实现成本,同时使研发人员在编码时产生预测试...养成单元测试的习惯和意识并非一朝一夕的事情,需要有彻底投入的决心,应该朝着投入越多越有效果越是投入的正向循环发展,如果只是一小段时间应付式地尝试推进,很容易陷入为了数据而做,被其他事务打断,效果不明显投入变少甚至放弃的困境...单元测试用例与验证的功能代码保持一致性,其他功能用例的修改不应该对其产生影响,测试结果也与用例运行顺序无关。 全面性。...没有任何断言验证的用例永远不会失败,但也没有任何意义,每一个单元测试,必定带有明确的验证目的,其输入与断言都应该是明确可预期的。...五、什么代码适合做单元测试 高质量高效率是我们追求的目标,而质量和效率似乎一直以来都呈负相关性,在两者发生冲突的时候,往往我们更优先保证的还是质量。

1.1K61

Go语言基准测试(benchmark)三部曲之三:提高篇

7448678 ns/op PASS ok benchmark-demo 7.751s 危险用法,提前避开 现在咱们对benchmark的了解已经比较全面了,可以覆盖大多数单元测试场景...这样的测试可能无法结束 func BenchmarkFibWrongA(b *testing.B) { for n := 0; n < b.N; n++ { fib(n) } } 上述代码在基准测试的时候可能永远不会结束...,这是因为b.N的值并不固定,可能超出了fib方法的设计范围,这样就导致出现意料之外的结果(本意是性能测试,fib的入参应该是设计范围内的),实际运行效果如下,红色箭头指向的状态一直在等待中,只能强行关闭了...只调用一次fib方法,代码如下所示 func BenchmarkFibWrongB(b *testing.B) { fib(b.N) } 和前面的BenchmarkFibWrongA比,fib的执行次数似乎少了...依旧没有明确答案,因此,代码也有可能永远不会结束 以本例中的fib为例,实际功能是斐波那契数列,我这边入参等于50的时候,fib方法的耗时是54秒,所以,如果b.N的值再大一些,例如等于100的时候,fib

32520

用 Swift 编写网络层单元测试

网络层的单元测试之所以让人感觉难以下手,原因主要有两点: 网络是个不稳定的外部依赖。 网络操作一般会涉及异步过程,而异步过程难以测试。...,例如时间、网络、数据库、线程或随机数产生器等。...stub 和 mock 很类似,它们最大的区别是,你会对 mock 进行断言,但不会对 stub 进行断言。换句话说,一旦你对一个 fake 进行断言了,它就是个 mock,否则就是个 stub。...由于 Swift 的反射非常弱鸡,似乎并没有什么特别好用的 mock 框架,所以一般来说可以用面向协议的思想来减少对象间的耦合,然后手动构建一个 fake 用于测试,当然这需要一些依赖注入技术的配合。...Self } extension Alamofire.Request: Responsable {} class NetworkManager { // static 属性自带 lazy 效果

2K20

浅谈单元测试

单元测试或是最好的项目文档。 很早之前在学习使用Java做测试的时候,得到过一个神秘大佬的帮助,在一起聊过单元测试,基本结论就是:单元测试大概率没啥鸟用。...众所周知,自动化测试相比手动测试一个比较明显的特点就是见效慢,需要积累一定的时间所产生的的价值才能超过手动测试,这还是在比较理想的情况下。某些时候可能永远也超不过。...而单元测试更甚,据大佬和吹牛逼的群聊中判断:好的单元测试代码大概是被测代码的2-3倍,这种工作量对于开发人员来讲是不可接受的。...之前对单元测试进行过一些尝试,写过一点文章: Maven和Gradle中配置单元测试框架Spock Groovy单元测试框架spock基础功能Demo Groovy单元测试框架spock数据驱动Demo...这些事儿,都是坚持了才会有效果。 ---- 郑重声明:文章首发于公众号“FunTester”,禁止第三方(腾讯云除外)转载、发表。

60120

聊一聊契约测试 | 洞见

为了保证API的正确性,我们会对外部系统的API进行测试(除非你100%相信外部系统永远正确和保持不变),这很可能就会导致一个问题,当外部系统并不那么稳定或者请求时间过长时,就会导致我们的测试效率很低,...第二,直接依赖于真实API的测试效果受限于API的稳定性和反映速度。 ?...契约测试:对服务之间的功能进行的测试,运行速度基本与单元测试相同。 E2E 测试:对系统前后端或者不同系统之间的集成测试,大多通过模拟UI操作的方式实现,运行速度三者之中最慢。 ?...这样解决了测试的独立性以及不会阻碍其他pipeline测试的效果,然后将通过测试的不同系统的package按照版本保存。...所以,改成CDCT之后,虽然产生了一定的提交顺序依赖,但是带来的更多的好处是确保契约文件的产生是调用端提出,并且保证当前最新,确保系统的正确性。

95750

浅谈Android单元测试的作用以及简单示例

每一个模块的代码很可能是由不同的人分开负责的,bug的产生由不同模块共同产生。...产生bug的原因有太多,并且由单人直接log或者断点调试难以处理,那么这种情况怎么办呢?...在这种情况下,程序员们面对的问题不再是要让整个项目到达理想的效果,而是让自己所面对的单元测试可以通过。这样就大大减少了多人开发中的交互成本。 简单示例 主要就两个文件: ?...我们calculate()方法的逻辑是返回a+b+1,所以是4,最终不会报错,如果我们把assertEquals中的4改成3,效果如下: ?...Assert方法 示例本身比较简单,但是对于刚刚接触单元测试读者可能对assertEquals()比较陌生,这是Assert这个类中的静态方法,单元测试中一般就是通过它来判断是否达到理想的效果

31721
领券