blocks|key|2722541|text|在大多数情况下，实现框架是一项复杂的任务，因为您开始用一些新的、坚实的框架部分重新构建旧代码。这些旧的部分必须开始与框架进行通信。旧的部分必须得到一些回调和返回，旧的部分必须以某种方式指出给用户，事实上，您突然有两个系统要测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2722542|如果您说您的应用程序本身并不那么复杂，但由于缺乏测试，它可能是重建应用程序的一个更好的选择。将一些常见的框架(如Zend+)放到测试中，收集您的需求，找出测试的框架是否适合这些需求，并决定重新开始是否有用。|2722543|我不太确定单元测试，但是NetBeans有一个内置的单元测试套件。|2722544|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Implementing a framework is in most cases a complex task because you kinda start rebuilding your old code with some new solid framework parts. Those old parts must start to communicate with the framework. The old parts must receive some callbacks and returnstates, the old parts must then somehow point that out to the user and in fact you suddenly have 2 systems to test.

If you say that you application itself isn't that complex but it has become due to lack of testing it might be a better option to rebuild the application. Put some common frameworks like Zend to the test, gather your requirements, find out if the tested framework suits for the requirements and decide if it's usefull to start over.

I'm not very sure of unit testing, but NetBeans has a built-in unit testing suite.

blocks|key|2722597|text|从规划的角度来看，我认为你有三个基本选择：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2722598|使用循环将代码修改为单元测试。|ordered-list-item|2722599|指定团队的一部分用单元测试对代码进行修改。|2722600|在处理代码时逐步引入单元测试。|2722601|第一种方法的持续时间可能比你预期的要长得多，而你可见的生产力也会受到影响。如果你使用它，你将需要得到所有利益相关者的认同。但是，您可以使用它来启动该过程。|2722602|第二种方法的问题是，您在编码者和测试作者之间创建了一个区别。编码器将不会感觉到任何所有权的测试维护。我认为这种做法值得避免。|2722603|第三种方法是最有机的，它让您从get开始进入测试驱动的开发。一个有用的单元测试可能需要一段时间才能积累。测试积累的缓慢速度实际上可能是一个优势，因为它使您有时间更好地编写测试。|2722604|考虑到所有的事情，我想我会选择按照方法1的精神进行适度的冲刺，然后是对方法3的承诺。|2722605|对于单元测试的一般原则，我推荐Gerard的“xUnit测试模式:重构测试代码”一书。|offset|length|2722606|entityMap|0|LINK|mutability|MUTABLE|url|http://xunitpatterns.com/^0|0|0|0|0|0|0|0|0|N|G|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|13|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|14|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|15|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|16|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|17|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|18|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1A|8|@]|9|@$S|1B|T|1C|1|1D]]|A|$]]|$1|U|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]]]

From a planning perspective, I think you have three basic choices: 

<ol>
<li>take a cycle to retrofit the code with unit tests</li>
<li>designate part of the team to retrofit the code with unit tests</li>
<li>introduce unit tests gradually as you work on the code</li>
</ol>

The first approach may well last a lot longer than you anticipate, and your visible productivity will take a hit. If you use it, you will need to get buy-in from all your stakeholders. However, you might use it to kickstart the process.

The problem with the second approach is that you create a distinction between coders and test writers. The coders will not feel any ownership for test maintenance. I think this approach is worth avoiding.

The third approach is the most organic, and it gets you into test-driven development from the get go. It may take some time for a useful body of unit tests to accumulate. The slow pace of test accumulation might actually be an advantage in that it gives you time to get good at writing tests.

All things considered, I think I'd opt for a modest sprint in the spirit of approach 1, followed by a commitment to approach 3. 

For the general principles of unit testing I recommend the book <a href="http://xunitpatterns.com/" rel="nofollow noreferrer">xUnit Test Patterns: Refactoring Test Code</a> by Gerard Meszaros.

blocks|key|1129077|text|我使用过PHPUnit，效果很好。PHPUnit和其他JUnit派生的项目一样，要求将要测试的代码组织成类。如果您的项目不是面向对象的，那么您将需要开始将非过程代码重构为函数，并将函数重构为类。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1129078|我没有亲自使用过JavaScript框架，不过我会想象这些框架还需要将代码构造成(至少)可调用的函数，如果不是完整的对象的话。|1129079|对于测试GUI应用程序，您可能会受益于使用硒，尽管一个由具有良好QA本能的程序员编写的清单可能工作得很好。我发现使用MediaWiki或您最喜欢的Wiki引擎是存储检查列表和相关项目文档的好地方。|1129080|entityMap|0|LINK|mutability|MUTABLE|url|http://www.phpunit.de/|1|http://seleniumhq.org/^0|4|7|0|0|0|L|1|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

I've used <a href="http://www.phpunit.de/" rel="nofollow noreferrer">PHPUnit</a> with good results. PHPUnit, like other JUnit-derived projects, requires that code to be tested be organized into classes. If your project is not object-oriented, then you'll need to start refactoring non-procedural code into functions, and functions into classes.

I've not personally used a JavaScript framework, though I would image that these frameworks would also require that your code be structured into (at least) callable functions if not full-blown objects.

For testing GUI applications, you may benefit from using <a href="http://seleniumhq.org/" rel="nofollow noreferrer">Selenium</a>, though a checklist written by a programmer with good QA instincts might work just fine. I've found that using MediaWiki or your favorite Wiki engine is a good place to store checklists and related project documentation.

blocks|key|2722666|text|如果代码非常混乱，那么很可能很难进行任何单元测试。只有足够松耦合和足够好设计的组件才能很容易地进行单元测试。但是，在您的情况下，功能测试可能更容易实现。我建议看一看硒。有了这个框架，您将能够同时测试GUI和后端。但是，最有可能的是，它不会像使用单元测试那样帮助您捕获bug。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2722667|entityMap|0|LINK|mutability|MUTABLE|url|http://seleniumhq.org/^0|2A|1|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

If the code is really messy, it's possible that it will be very hard to do any unit testing. Only sufficiently loosely coupled and sufficiently well designed components can be unit tested easily. However, functional testing may be a lot easier to implement in your case. I would recommend taking a look at <a href="http://seleniumhq.org/" rel="nofollow noreferrer">Selenium</a>. With this framework, you will be able to test your GUI and the backend at the same time. However, most probably, it won't help you catch the bugs as well as you could with unit testing.

blocks|key|1199432|text|G‘’day，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1199433|编辑：--我刚刚快速浏览了"单元测试的艺术“的第一章，它也可以作为免费PDF在图书网站上使用。它将为您提供一个很好的概述，您正试图做什么与一个单元测试。|offset|length|style|BOLD|1199434|我假设您将使用xUnit类型框架。一些初步的高层想法是：|1199435|编辑：确保每个人都同意什么是好的单元测试。我建议使用上面的概述章节作为一个很好的起点，如果需要的话，从这里开始。想象一下，当人们对什么是“好的”单元测试有不同的理解时，人们会热情地跑去创建大量的单元测试。对于你来说，将来有25%25的单元测试是无用的、可重复的、可靠的等等，这对你来说是很糟糕的。|ordered-list-item|1199436|一次添加测试以覆盖小块代码。也就是说，不要创建一个单一的单块任务来添加现有代码库的测试。|1199437|修改任何现有进程，以确保为编写的任何新代码添加新测试。使之成为代码评审过程的一部分，即必须为新功能提供单元测试。|1199438|扩展任何现有的bug修复过程，以确保创建新的测试以显示是否存在该错误并证明该错误是否存在。注意:不要忘记回滚您的候选补丁，再次引入bug，以验证只有单个修补程序才纠正了问题，并且它没有被多种因素所修复。|1199439|编辑:当您开始构建测试的数量时，开始运行它们，就像夜间的回归测试一样，以检查新功能没有破坏什么。|1199440|成功地运行所有现有测试和候选错误评审过程的条目标准。|1199441|编辑：开始保存测试类型的目录，即测试代码片段，以便更容易地创建新的测试。无时无刻不在重新发明轮子。为测试在代码库的一部分中打开文件而编写的单元测试与编写用于在代码库的不同部分中打开不同文件的测试代码的单元测试类似。对这些产品进行编目，使其易于找到。|1199442|编辑：--在这里，您只修改现有类的几个方法，创建一个测试套件来保存该类的完整测试集。然后，只将要修改的方法的单个测试添加到此测试套件中。这使用xUnit+termonology，因为我现在假设您将使用像PHPUnit这样的xUnit框架。|1199443|使用标准约定来命名您的测试套件和测试，例如testSuite_classA，它将包含像test__test_function这样的单独测试。例如，test_fopen_bad_name和test_fopen_bad_perms等，这有助于在代码库周围移动和查看其他人的测试时将噪音降到最低。这也有利于帮助人们从一开始就开始命名他们的测试，释放他们的思想去做一些更有趣的事情，比如测试本身。|1199444|编辑：，在这个阶段我不会使用TDD。根据定义，TDD将需要在更改到位之前出现的所有测试，因此在添加新的testSuites以覆盖您正在处理的类时，您将在整个地方都有失败的测试。相反，添加新的testSuite，然后根据需要添加单个测试，这样您的测试结果中就不会出现大量的失败测试噪音。而且，就像一猜所指出的，在这个时候增加学习TDD的任务会使你慢下来。当你有空闲时间时，把学习TDD作为一项要完成的任务。没那么难。|1199445|因此，您需要一个工具来跟踪那些存在testSuite但还没有编写测试来覆盖类中其他成员函数的现有类。通过这种方式，您可以跟踪测试覆盖率有漏洞的地方。我在这里讲的是一个高层，在这里，您可以生成一个类和特定成员函数的列表，而这些类和特定的成员函数目前还没有测试。测试和testSuites的标准命名约定将对您有很大的帮助。|1199446|我会增加更多的点，因为我认为他们。|1199447|HTH|1199448|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/1933988274|1|http://www.manning.com/osherove/osherove_meapch1.pdf|2|http://www.artofunittesting.com/Chapters/The_Basics_Of_Unit_Testing^0|0|0|3|E|7|0|X|5|1|13|4|2|0|0|0|3|0|0|0|0|0|1C|0|0|Q|0|0|3G|0|0|3B|0|0|5E|0|0|5R|0|0|4F|0|0|H|0|0|3|0^^$0|@$1|2|3|4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1N|8|@$D|1O|E|1P|F|G]]|9|@$D|1Q|E|1R|1|1S]|$D|1T|E|1U|1|1V]|$D|1W|E|1X|1|1Y]]|A|$]]|$1|H|3|I|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|20|8|@$D|21|E|22|F|G]]|9|@]|A|$]]|$1|M|3|N|5|L|7|23|8|@]|9|@]|A|$]]|$1|O|3|P|5|L|7|24|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|25|8|@]|9|@]|A|$]]|$1|S|3|T|5|L|7|26|8|@$D|27|E|28|F|G]]|9|@]|A|$]]|$1|U|3|V|5|L|7|29|8|@$D|2A|E|2B|F|G]]|9|@]|A|$]]|$1|W|3|X|5|L|7|2C|8|@$D|2D|E|2E|F|G]]|9|@]|A|$]]|$1|Y|3|Z|5|L|7|2F|8|@$D|2G|E|2H|F|G]]|9|@]|A|$]]|$1|10|3|11|5|L|7|2I|8|@$D|2J|E|2K|F|G]]|9|@]|A|$]]|$1|12|3|13|5|L|7|2L|8|@$D|2M|E|2N|F|G]]|9|@]|A|$]]|$1|14|3|15|5|L|7|2O|8|@$D|2P|E|2Q|F|G]]|9|@]|A|$]]|$1|16|3|17|5|6|7|2R|8|@$D|2S|E|2T|F|G]]|9|@]|A|$]]|$1|18|3|19|5|6|7|2U|8|@$D|2V|E|2W|F|G]]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|2X|8|@]|9|@]|A|$]]]|1B|$1C|$5|1D|1E|1F|A|$1G|1H]]|1I|$5|1D|1E|1F|A|$1G|1J]]|1K|$5|1D|1E|1F|A|$1G|1L]]]]

G'day,

Edit: I've just had a quick look through the first chapter of "<a href="https://rads.stackoverflow.com/amzn/click/com/1933988274" rel="nofollow noreferrer" rel="nofollow noreferrer">The Art of Unit Testing</a>" which is also available as <a href="http://www.manning.com/osherove/osherove_meapch1.pdf" rel="nofollow noreferrer">a free PDF</a> at the <a href="http://www.artofunittesting.com/Chapters/The_Basics_Of_Unit_Testing" rel="nofollow noreferrer">book's website</a>. It'll give you a good overview of what you are trying to do with a unit test.

I'm assuming you're going to use an xUnit type framework. Some initial high-level thoughts are:

<ol>
<li>Edit: make sure that everyone is is agreement as to what constitutes a good unit test. I'd suggest using the above overview chapter as a good starting point and if needed take it from there. Imagine having people run off enthusiastically to create lots of unit tests while having a different understanding of what a "good" unit test. It'd be terrible for you to out in the future that 25% of your unit tests aren't useful, repeatable, reliable, etc., etc..</li>
<li>add tests to cover small chunks of code at a time. That is, don't create a single, monolithic task to add tests for the existing code base.</li>
<li>modify any existing processes to make sure new tests are added for any new code written. Make it a part of the review process of the code that unit tests must be provided for the new functionality.</li>
<li>extend any existing bugfix processes to make sure that new tests are created to show presence and prove the absence of the bug. N.B. Don't forget to rollback your candidate fix to introduce the bug again to verify that it is only that single patch that has corrected the problem and it is not being fixed by a combination of factors.</li>
<li>Edit: as you start to build up the number of your tests, start running them as nightly regression tests to check nothing has been broken by new functionality.</li>
<li>make a successful run of all existing tests and entry criterion for the review process of a candidate bugfix.</li>
<li>Edit: start keeping a catalogue of test types, i.e. test code fragments, to make the creation of new tests easier. No sense in reinventing the wheel all the time. The unit test(s) written to test opening a file in one part of the code base is/are going to be similar to the unit test(s) written to test code that opens a different file in a different part of the code base. Catalogue these to make them easy to find.</li>
<li>Edit: where you are only modifying a couple of methods for an existing class, create a test suite to hold the complete set of tests for the class. Then only add the individual tests for the methods you are modifying to this test suite. This uses xUnit termonology as I'm now assuming you'll be using an xUnit framework like PHPUnit.</li>
<li>use a standard convention for the naming of your test suites and tests, e.g. testSuite_classA which will then contain individual tests like test__test_function. For example, test_fopen_bad_name and test_fopen_bad_perms, etc. This helps minimise the noise when moving around the code base and looking at other people's tests. It also has then benefit of helping people when they come to name their tests in the first place by freeing up their mind to work on the more interesting stuff like the tests themselves.</li>
<li>Edit: i wouldn't use TDD at this stage. By definition, TDD will need all tests present before the changes are in place so you will have failing tests all over the place as you add new testSuites to cover classes that you are working on. Instead add the new testSuite and then add the individual tests as required so you don't get a lot of noise occurring in your test results for failing tests. And, as Yishai points out, adding the task of learning TDD at this point in time will really slow you down. Put learning TDD as a task to be done when you have some spare time. It's not that difficult.</li>
<li>as a corollary of this you'll need a tool to keep track of the those existing classes where the testSuite exists but where tests have not yet been written to cover the other member functions in the class. This way you can keep track of where your test coverage has holes. I'm talking at a high level here where you can generate a list of classes and specific member functions where no tests currently exist. A standard naming convention for the tests and testSuites will greatly help you here.</li>
</ol>

I'll add more points as I think of them.

HTH

blocks|key|1129153|text|你应该给自己买一本有效地使用遗产代码。这将为您提供关于如何将测试引入未编写用于测试的代码的良好指导。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1129154|TDD很棒，但是您确实需要首先测试现有代码，以确保您所做的更改不会在引入更改时更改现有的所需行为。|1129155|然而，现在引入TDD会使您在返回之前慢很多，因为改造测试，即使是在您正在更改的区域，也会在变得简单之前变得更加复杂。|1129156|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0131177052^0|9|9|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

You should get yourself a copy <a href="https://rads.stackoverflow.com/amzn/click/com/0131177052" rel="noreferrer" rel="nofollow noreferrer">Working Effectively with Legacy Code</a>. This will give you good guidance in how to introduce tests into code that is not written to be tested.

TDD is great, but you do need to start with just putting existing code under test to make sure that changes you make don't change existing required behavior while introducing changes.

However, introducing TDD now will slow you down a lot before you get back going, because retrofitting tests, even only in the area you are changing, is going to get complicated before it gets simple.

blocks|key|2722840|text|也许这张单子能帮你和你的伙伴们重新构建所有的东西：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2722841|使用UML设计和处理异常(语言)|ordered-list-item|offset|length|2722842|使用BPMS，设计您的工作流程，这样您就不会挣扎(管理)|2722843|获取也支持javascript后端的php框架列表(例如，使用jQuery的Zend+)|2722844|将这些框架进行比较，并采用最符合项目设计和之前使用的编码结构的框架。|2722845|您应该考虑使用ezComponents和Dtrace之类的工具进行调试和测试。|2722846|不要害怕改变;)|2722847|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Unified_Modeling_Language|1|http://en.wikipedia.org/wiki/Business_process_management^0|0|D|2|0|0|P|2|1|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|11|8|@]|9|@$E|12|F|13|1|14]]|A|$]]|$1|G|3|H|5|D|7|15|8|@]|9|@$E|16|F|17|1|18]]|A|$]]|$1|I|3|J|5|D|7|19|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|1A|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1B|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|1C|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]|Y|$5|T|U|V|A|$W|Z]]]]

Maybe this list will help you and your mates to re-structure everything:

<ol>
<li>Use UML, to design and handle exceptions (<a href="http://en.wikipedia.org/wiki/Unified_Modeling_Language" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/Unified_Modeling_Language</a>)</li>
<li>Use BPMS, to design your work-flow so you won't struggle (<a href="http://en.wikipedia.org/wiki/Business_process_management" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/Business_process_management</a>)</li>
<li>Get a list of php frameworks which also support javascript backends (e.g. Zend with jQuery)</li>
<li>Compare these frameworks and take the one, which matches the most to your project desgin and the coding structure used before</li>
<li>You should may be consider using things like ezComponents and Dtrace for debugging and testing</li>
<li>Do not be afraid of changes ;)</li>
</ol>

blocks|key|2722906|text|为了补充其他优秀的答案，我同意在一次访问中从0%25到100%25的覆盖率是不现实的--但是每次修复bug时，您绝对应该添加单元测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2722907|您说有相当多的bug和不愉快的客户--我会非常肯定地将严格的TDD集成到错误修复过程中，这比全面实现它容易得多。毕竟，如果确实存在一个需要修复的bug，那么创建一个可以复制它的测试就可以达到不同的目标：|2722908|它很可能是一个最小的测试用例来证明确实存在一个问题|unordered-list-item|2722909|如果您确信(目前正在失败的)测试突出了报告的问题，那么您将确定您的更改是否修复了它|2722910|它将永远作为一个回归测试，将防止同样的问题再次出现在未来。|2722911|向现有项目引入测试是困难的，而且可能是一个漫长的过程，但是在修复bug的同时进行测试是这样做的理想时机(与在“正常”意义上逐步引入测试的同时)，如果不抓住这个机会并从bug报告中制造柠檬水，那将是一种耻辱。:-)|2722912|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|R|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|S|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|T|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|N|$]]

Just to add to the other excellent answers, I'd agree that going from 0% to 100% coverage in one go is unrealistic - but that you should definitely add unit tests every time you fix a bug.

You say that there are quite a lot of bugs and unhappy customers - I'd be very positive about incorporating strict TDD into the bugfixing process, which is much easier than implementing it overall. After all, if there really is a bug there that needs to be fixed, then creating a test that reproduces it serves various goals:

<ul>
<li>It's likely to be a minimal test case to demonstrate that there really is an issue</li>
<li>With confidence that the (currently failing) test highlights the reported problem, you'll know for sure if your changes have fixed it</li>
<li>It will forever stand as a regression test that will prevent this same issue recurring in future.</li>
</ul>

Introducing tests to an existing project is difficult and likely to be a long process, but doing them at the same time as fixing bugs is such an ideal time to do so (parallel to introducing tests gradually in a "normal" sense) that it would be a shame not to take that chance and make lemonade from your bug reports. :-)

blocks|key|1129256|text|对于GUI测试，您可能希望查看硒+(正如Ignas已经指出的那样)，或者您可能也想看看这个工具：STIQ。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1129257|祝你好运！|1129258|entityMap|0|LINK|mutability|MUTABLE|url|http://seleniumhq.org/|1|http://storytestiq.solutionsiq.com/wiki/Getting_Started^0|F|1|0|1C|4|1|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

For GUI testing you may want to take a look at <a href="http://seleniumhq.org/" rel="nofollow noreferrer">Selenium</a> (as Ignas R pointed out already) OR you may wanna take a look at this tool as well: <a href="http://storytestiq.solutionsiq.com/wiki/Getting_Started" rel="nofollow noreferrer">STIQ</a>.

Best of luck!

blocks|key|1129260|text|在某些情况下，进行自动测试可能不是一个好主意，特别是当代码库很脏并且PHP将其行为与Javascript混合时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1129261|最好是从一个简单的清单(有链接，使它更快)开始，测试应该在每次交付之前(手动)完成。|1129262|在一个有3年历史的雷场中编码时，最好用许多错误检查来保护自己。为每一种情况编写正确的错误消息所花费的15分钟不会丢失。|1129263|使用桥接方法:桥接丑陋、冗长的函数折叠()，调用fnew()+(它是一些干净类的包装器)，调用折叠和fnew，比较结果，记录差异，将代码投入生产，等待您的鱼。在进行此操作时，始终使用一个循环进行重构，使用anOTHER循环来更改结果(甚至不要修复旧行为中的bug，只需将其连接起来)。|1129264|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

In some cases, doing automatic testing may not be such a good idea, especially when the code base is dirty and PHP mixes it's behavior with Javascript. 

It could be better to start with a simple checklist (with links, to make it faster) of the tests that should be done (manually) on the thing before each delivery. 

When coding in a 3 years old minefield, better protect yourself with many error checking. The 15 minutes spent writing THE proper error message for each case will not be lost.

Use the bridging method: bridge ugly lengthy function fold() with a call to fnew() which is a wrapper around some clean classes, call both fold and fnew and compare result, log differences, throw the code into production and wait for your fishes. When doing this, always use one cycle for refactoring, anOTHER cycle for changing result (do not even fix bugs in old behavior, just bridge it).

blocks|key|1199688|text|我同意KOHb的观点，硒是必须的！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1199689|也可以看看PHPure，|offset|length|1199690|他们的软件记录一个正常运行的php网站的输入和输出，然后自动编写不访问外部源(db、文件等)的函数的phpunit测试。|1199691|这不是百分之百的解决方案，但这是一个很好的开始|1199692|entityMap|0|LINK|mutability|MUTABLE|url|http://www.phplegacy.com/^0|0|5|6|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

I agree with KOHb, Selenium is a must !

Also have a look at <a href="http://www.phplegacy.com" rel="nofollow">PHPure</a>,

Their software records the inputs and outputs from a working php website, and then automatically writes phpunit tests for functions that do not access external sources (db, files etc..).

It's not a 100% solution, but it's a great start

I've got a big project written in PHP and Javascript. The problem is that it's become so big and unmaintainable that changing some little portion of the code will upset and probably break a whole lot of other portions.

I'm really bad at testing my own code (as a matter of fact, others point this out daily), which makes it even more difficult to maintain the project.

The project itself isn't that complicated or complex, it's more the way it's built that makes it complex: we don't have predefined rules or lists to follow when doing our testing. This often results in lots of bugs and unhappy customers.

We started discussing this at the office and came up with the idea of starting to use test driven development instead of the develop like hell and maybe test later (which almost always ends up being fix bugs all the time).

After that background, the things I need help with are the following:

<ol>
<li>How to implement a test
framework into an already existing
project? (3 years in the
making and counting)</li>
<li>What kind of frameworks are there
for testing? I figure I'll need one
framework for Javascript and
one for PHP.</li>
<li>Whats the best approach for testing
the graphical user interface?</li>
</ol>

I've never used Unit Testing before so this is really uncharted territory for me.

How do I implement a test framework in a legacy project

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个用PHP和Javascript编写的大型项目。问题是，它变得如此庞大和不可维护，以至于更改代码的一些小部分将使其不愉快，而且可能会破坏大量其他部分。我在测试自己的代码方面真的很糟糕(事实上，其他人每天都会指出这一点)，这使得维护项目变得更加困难。项目本身并不是那么复杂或复杂，更多的是它的构建方式使它变得复杂:我...

问如何在遗留项目中实现测试框架？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在遗留项目中实现测试框架？EN