@sockpuppet9527 #12

这真是个常识问题，你可能不太了解，但是相关的资料应该不难找，关于测试的书基本上首先都会讲这个问题.

我有这样的建议，你先把使用 Mock 的好处找到然后给列出来，因为 Mock 是几乎所有单元测试框架中都要用的，可以说那是必备的东西.

我估计谷歌上的资料已经很多很多了，因为我看到的书首先都要讲这个.

当然你们在实践的过程中可能遇到的问题让你感觉特别的无奈，不想写这个东西，然后你对这个可恶的东西有了很强烈的情绪.

这个是人之常情，每个人都会这样，但你想一下 Mock，广泛存在于所有单元测试框架中，这个现实就知道，比起这个东西完全没用来说，更大的可能是用错了，有句话说垃圾是放错的资源，何况这个东西显然不是垃圾.

等你把好处列出来之后 "现在项目明明可以用实际环境来测试，为什么不用呢？还必须要 Mock 住环境，这不是多次一举？"这个问题自然而然就回答了，那么你也就知道了，Mock 真正要解决的问题，如果某些问题的确不适合它来解决，那么你也就不用再费心了.

我也把之前看到的资料稍微整理整理发到这上面来供你参考，也许会有点帮助我也复习复习.

@niubee1 #10
这不就是测试出动开发吗？目前研究表明这个方法还是能够提高效率和代码质量的，至少不会变差.[1]
软件业目前就是这样，很多很多上世纪都出现了概念，但很多程序员却根本就不知道，有时候让人感觉挺悲哀的.[2]
多读书怎么强调也不为过.

[1] AndyOram, GregWilson. 软件之道[M]. 人民邮电出版社, 2012.
[2] Barr A . The Problem with Software[C]// 2018.

@AndyAO #8 更改上面一段，删除掉不小心打错了部分

而至于万一测试没问题，但上线之后有问题该怎么办，这个也是老问题了，关于测试的书里很多都谈到了.
有点类似于科学实验，发火箭造飞机都不是按照实际情况来进行测试的，也都不可能完全按照现实情况来进行测试.

关于 UT 阻碍修改的问题.
在进行大范围的更改的时候，就应该舍去.
因为测试的很多都是实现细节，而不是行为本身实现，细节本来就可以改的.
这个问题自从 UT 诞生以来就有了，上世纪 90 年代还有人这么说.
要再写单元测试的同时也要写行为测试，当然有必要的话还可以写更高层的.
这样的话，如果更改已经明显越过测试了，那就应该舍弃.

而至于万一测试没问题，但上线之后有问题该怎么办，这个也是老问题了，关于测试的书里很多都谈到了.
有点类似于科学实验的意思，发个火箭造个飞机什么的，也都不可能完全按照现实情况来进行测试内容测试就不能叫测试.

至于论证的话比较偏哲学所以在这里我也就不写了，相关的书里都有.

我写测试也不太专业，我也在补课，感觉很多书都讲的不错，书比较老，也有很多的养分，如果不吸取前人的经验，那么就会重复的方案，90 年代大家都遇到过的错误.

之前优酷就出过这么个东西，我买了还不错，最后收回成本了，那个路由器也用了很多年，最后坏掉了，我还把里面专门用来 cdn 的储存卡给拔出来自己用的.
不过后来这个项目已经停了，不知道为什么，京东还有勇气继续做.

头像和微软的那个韩先生好像很相似.
刚开始我还以为是微软的人在发这个.

@jorneyr #30
原来你是这个意思.
那我感到不再困惑了!

还是像之前说的那样,大多数人都不愿意走出自己的舒适区,毕竟这样很累,风险很高.

更新更好的东西往往和之前的不合群.
终于买了个汽车，然后一拍方向盘，大喊'驾'
结果发现汽车岿然不动
发誓不再用汽车了，汽车真是个不合群的东西，和马和驴都不一样

对于上面那个问题再补充一些

在 PowerShell 上一切都是对象，包括传递参数这个过程，在其他文本 Shell 中，后面打的所有字都是字符串，但在 PowerShell 中后面的东西都是参数列表，本质上也是对象是需要经过解析之后再来调用的，而`-`是参数列表中参数名字的语法.

所以错误提示为`Error: Unable to access jarfile .encoding=UTF-8`,`-Dfile`被 PowerShell 解释成参数的名字，所以就更没传递进去.

面向对象之后是很有好处的，尤其是命令比较复杂的时候，直接可以在外面写个列表，然后直接传进去，根本就不需要折腾字符串了.

当然，如果你有个早就写好或者从网上直接复制粘贴的巨长无比的可读线几乎没有的字符串命令，那么在上面说了最好的方法就是直接用`--%`，告诉 PowerShell 停止使用面向对象的思维来考虑问题，直接当所有东西都是字符串，那么问题就迎刃而解了

参考资料:
about_Command_Syntax
about_Parsing

@jorneyr #25
算了，我也不想说半截话，就把你那个问题给答完了

你那个问题在谷歌上这么搜索,首个结果就会有答案`PowerShell "-Dfile.encoding=UTF-8"`

powershell - Specify the default file encoding in Java - Stack Overflow
https://stackoverflow.com/questions/33393001/specify-the-default-file-encoding-in-java

所以说这就是个动动手指的问题啊，除非你不能翻墙，谷歌用不了，否则我对你不理解这个问题，感到有点难以置信

除了上面说的方法，还有一种方法是加入`--%`，这个在与调用相关的文档上就有，所以说你哪怕有一点心思想学一下 PowerShell，那么你就不会犯这个错误

那么总结下来就是

`java -jar -Dfile.encoding=UTF-8 JavaHelloWorld.jar` 语法错误

`java -jar "-Dfile.encoding=UTF-8" JavaHelloWorld.jar` 语法正确

`java -jar -Dfile.encoding=UTF-8 JavaHelloWorld.jar` 语法正确

这个你仔细观察一下从控制台的高亮上就能够看出来


我就不多说了，希望对你有点帮助

@orannge #23

基本同意你的观点，不过我想补充一下 :

你刚才说的那个场景，如果只是暂时用用，那么可以直接使用 CMD 等其他方法绕开，坏处就是体验有割裂，突然用不了 PowerShell 上的各种便利功能

如果经常要用，想要让所有的操作都能和 Cmdlet 有类似体验，那么其实有途径封装成 Cmdlet

比如说 PowerShell 最近就出了专门的工具来将这个封装工作更加的自动化

[Announcing PowerShell Crescendo Preview.1 | PowerShell]( https://devblogs.microsoft.com/powershell/announcing-powershell-crescendo-preview-1/)


关键是看谁用，如果真心的想使用 PowerShell，发现不懂的就去学，那么肯定不会将二进制数据直接传到管道里面去

因为管道里面默认是对象，要不就是字符串，要不就是别的对象，二进制数据也是要封装在对象里面的，这个只要是学过基本概念的就熟悉

开发跨平台 CLI 工具，在 PowerShell 遇到的问题就是 : 那些没有学过 PowerShell 基本概念的人，要求 PowerShell 和其他基于文本的 Shell，完全相同的人，使用上的兼容性会出问题，如果是经常使用 PowerShell，那些问题基本上都是可以绕过去的，不是什么大事，微软不傻，不可能把兼容性做得如此烂，以至于各种工具都用不了，如上所述，关于兼容性问题改进，一直都在持续

@jorneyr #25
去谷歌搜一下就明白的事情了，你非要让我给你粘贴上来，不学习就是这么可怕
基本概念都没搞清楚

建议等等红米
如果没有特别的需求
买个主流机型，后面好处很多

经常能看见这种问题，抛出比较惊人的说法，问问大家的意见是什么样子的，但是对于那个说法，本身却没有给出任何的证据。

知乎上经常会说「先问有没有」，我觉得这是说的很好的。

WPF 刚更新了，而且.NET5 也是支持 WPF 的，没有理由说已经死了。

等到已经不更新了，甚至官方直接明说放弃支持了，那个时候再说死了这种话，那样才对吧。

"WPF 已死"的结论是从哪里来的？

那是因为你不懂 PowerShell 的语法
后面几位的回复和楼主基本上都是相同的

先假设 PowerShell 和之前的其他 Shell 用法是相同的
然后按照那个方法使用，发现用不了之后就感到有点失望

PowerShell 这是个新工具，使用它不是自然而然的，是需要一些学习成本的

而其实这个问题去谷歌一下就马上能找到答案，可能大多数人真的不太喜欢离开自己的舒适区吧

@jorneyr #20

#20 不小心点错了,刚刚的回复不是给你的.

#20 #18

现在已经很少有人会用 ISE 了,你应该是有段时间没有用 PowerShell 了.
目前 PowerShell 已经更新到 PowerShell 7,依托于.Net Core+Visual Studio Code,实现了跨平台.ISE 已经停止更新了.

目前新 PowerShell 的开发一直都很活跃,没有停下的迹象,开发团队的博客经常会更新,GitHub 上面的仓库也很活跃,这说明有很多人在使用它,而且微软看好它的未来.

C#不符合'脚本语言'的定义(维基百科上的,可以说是大多数人的看法),它是静态类型的,有冗长的依法规则,执行之前要先进行编译,而且它的执行速度和 C 很接近.

这些都说明 C#不是什么脚本语言.

所以你的看法令人感到困惑.

看到前面很多人提到了 PowerShell 模块加载的速度问题.
其实模块没有必要提前进行加载,除非直接对全局进行了更改,比如说 posh-git.
在 PowerShell 中,只要你的模块是安装在指定目录中的,可以在首次使用的时候自动加载.
很多人可能不清楚这点,所以就把很多的模块在最初全部导入了,那速度肯定快不了.
不过,如果这些模块确定要使用,那么提前导入还是有好处的,加快了使用时候的速度和提高了一致性.

@bthulu #16 苹果和特斯拉也是