blocks|key|411142|text|您可以使用Selenium，这是一个web测试框架。这样，您就可以断言要对DOM中的元素应用什么样式，等等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|411143|Selenium|offset|length|411144|否则，你不确定你的目标是什么。单元测试，顾名思义，就是测试“单元”，对我来说，这只对代码有意义，对css没有意义。|411145|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.seleniumhq.org/^0|0|0|8|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

You could use Selenium, which is a web testing framework. This way you could assert what styles are to be applied to elements in the DOM etc. 

<a href="http://docs.seleniumhq.org/" rel="noreferrer">Selenium</a>

Otherwise, not sure what your aim is. Unit testing is, as the name suggests, testing 'Units', and to me, this only makes sense with code, not css.

blocks|key|411147|text|目前，了解CSS是否正常工作是通过视觉确定的。到目前为止，测试它的最佳方法是在您的开发机器上安装多个浏览器。开始使用Firefox上的Firebug和Web+Developer等工具，忘记单元测试CSS，直到它完全图灵。:-)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|411148|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Currently, understanding whether CSS is working properly or not is visually determined. So far, the best way to test it is through installing multiple browsers on your dev machine. Start using tools like Firebug and Web Developer on Firefox, and forget about Unit testing CSS until it becomes Turing complete. :-)

blocks|key|3468917|text|您可以使用PhantomCSS进行自动视觉比较。然后，您可以创建CSS模块单元测试页面，该页面仅加载基本CSS样式并以组件的所有状态显示组件，但不从其他组件加载CSS。然后你可以将它与加载了所有模块的完整CSS文件进行比较。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3468918|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You can use PhantomCSS for automatic visual comparison. And then you can create CSS module unit test page that only loads the base CSS styles and displays the component in all it's states, but does not load CSS from other components. And then you can compare it to full CSS file with all modules loaded.

blocks|key|414623|text|我不明白为什么我们不能或者不应该对CSS进行单元测试。以下是我脑海中的场景：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|414624|我有一个CSS框架，是由多个模块化的CSS文件和驱动我的5个网站。|414625|Ex+:+base.css+/+form.css+/+article.css+etc.|code-block|syntax|javascript|414626|假设我为了一个应用于站点#1的需求而对base.css进行了更改，如果没有=>，我可能会破坏站点#2的样式。|414627|如果我的CSS框架是构建在LESS或SASS之上，那么CSS单元测试就更有意义了:一个宏中的改变可能会破坏所有的样式。。|offset|length|style|CODE|414628|entityMap^0|0|0|0|0|D|4|I|4|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]|$M|Z|N|10|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

I don't understand why we couldn't or shouldn't unit test CSS. Here's the scenario I have in mind :

I have a CSS framework that is made of multiple modular CSS files and that drive 5 of my sites.

<pre><code>Ex : base.css / form.css / article.css etc.
</code></pre>

Imagine I make a change to base.css for a requirement applying to Site #1 only => I may break Site #2 styling without.

CSS unit test would be even more pertinent if my CSS framework is build on top of <code>LESS</code> or <code>SASS</code> : a change in a macro could break all the styling.
.

blocks|key|3468942|text|我认为在浏览器(客户端)中“单元测试”CSS是可能的。它更像是一个自动检查器，而不是一个单元测试：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3468943|3468944|评估我们希望为特定CSS类或ID保留的最终CSS属性条件(结果)。|ordered-list-item|3468945|我们需要测试文档HTML来呈现静态内容和CSS。所有元素都应该以单独的containers.|3468946|After呈现形式包含在内容中，使用javascript检查所选目标的最终或最终结果属性，并输出不匹配的元素。|3468947|3468948|单元测试用例：|3468949|DOM选择器：|3468950|.test1
.test2
#test3|code-block|syntax|javascript|3468951|这应该始终是最终的属性：|3468952|CSSAttribute1,+CSSFinalValue1
CSSAttribute2,+CSSFinalValue2
CSSAttribute3,+CSSFinalValue3|3468953|在JS中设置测试规则的函数可以是：|3468954|addCSSUnitTest(".test1,+.test2,+#test3",+"margin-left:+4px;+font-size:+8px");|3468955|然后我们检查DOM元素是否有这个最后的属性。|3468956|所有这些都是在渲染后用javascript完成的。但不管怎样，这是不切实际的，因为您将不得不构建许多单元测试用例，这将显着增加您的代码。|3468957|此外，您应该始终有一个跨浏览器的“兼容性”的reset.css。|3468958|一个替代将是指定您知道应该保留其整个属性的CSS类。创建DOM选择器列表。使用jQuery获取CSS+class属性(直接来自CSS类)，并检查它们是否保留在目标DOM元素中。最后一种方法可以几乎完全自动化，但需要更复杂的javascript检查器。最后一个不会检查CSS的ID选择器(例如"#test3")，只检查类(例如".test1")|offset|length|style|BOLD|3468959|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|2|2|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1H|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1I|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1J|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1L|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1M|8|@]|9|@]|A|$]]|$1|O|3|P|5|Q|7|1N|8|@]|9|@]|A|$R|S]]|$1|T|3|U|5|6|7|1O|8|@]|9|@]|A|$]]|$1|V|3|W|5|Q|7|1P|8|@]|9|@]|A|$R|S]]|$1|X|3|Y|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Z|3|10|5|Q|7|1R|8|@]|9|@]|A|$R|S]]|$1|11|3|12|5|6|7|1S|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1T|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|1U|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|1V|8|@$19|1W|1A|1X|1B|1C]]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]]|1E|$]]

I think it would be possible in the browser (client-side) to "unit test" CSS. It would be more like an automated checker than an unit testing:

<ol>
<li>Evaluate the final CSS attribute conditions we would like to preserve for a particular CSS class or ID (the result).</li>
<li>We require a testing document HTML to render the static content and CSS. All elements should be included in the content in separate containers.</li>
<li>After rendering, check with javascript the final or resulting final attributes of the selected targets and output non matching elements.</li>
</ol>

Unit testing case:

DOM selectors:

<pre><code>.test1
.test2
#test3
</code></pre>

This should always be the final attributes:

<pre><code>CSSAttribute1, CSSFinalValue1
CSSAttribute2, CSSFinalValue2
CSSAttribute3, CSSFinalValue3
</code></pre>

A function to set test rules in JS could be:

<pre><code>addCSSUnitTest(".test1, .test2, #test3", "margin-left: 4px; font-size: 8px");
</code></pre>

Then we check if DOM elements have this final attributes.

All done in javascript after rendering. But anyway this is not practical because you will have to construct many unit test cases that will increase your code significantly.

Also you should always have a reset.css for cross-browser "compatibility".

An alternative would be to designate CSS classes that you know should preserve their entire attributes. Create a list of DOM selectors. Use jQuery to get CSS class attributes (directly from the CSS class) and check if they are preserved in the target DOM elements. This last method could be almost fully automated, but will require a more complex javascript checker. This last one will not check CSS for ID selectors (e.g. "#test3"), only classes (e.g. ".test1")

blocks|key|3255866|text|有一种有趣的方法，我从未尝试过，但可能会奏效：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3255867|3255868|您可以创建提供所有组件的样例页面(如https://getboostrap.com)，等等。使用Huxley|ordered-list-item|offset|length|3255869|测试的|3255870|unordered-list-item|3255871|3255872|Et+voilà:)|3255873|entityMap|0|LINK|mutability|MUTABLE|url|https://getboostrap.com/|1|https://github.com/facebook/huxley^0|0|0|I|N|0|1C|6|1|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|10|8|@]|9|@$F|11|G|12|1|13]|$F|14|G|15|1|16]]|A|$]]|$1|H|3|I|5|6|7|17|8|@]|9|@]|A|$]]|$1|J|3|-4|5|K|7|18|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1A|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]|W|$5|R|S|T|A|$U|X]]]]

There's an interesting approach which I've never tried, but may work:

<ol>
<li>You create sample pages (à la <a href="https://getboostrap.com" rel="nofollow">https://getboostrap.com</a>) providing all components, etc.</li>
<li>You test with <a href="https://github.com/facebook/huxley" rel="nofollow">Huxley</a></li>
</ol>

Et voilà :)

blocks|key|3469099|text|有一个新的名为Quixote的css单元测试库。它不是直观地比较图像，而是查看代码。与Selenium不同，您不必断言特定的样式，相反，您可以这样说：“它应该居中”或“左侧应该是这个元素右侧的10px”。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3469100|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/jamesshore/quixote^0|7|7|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]]]]

There is a new css unit testing library called <a href="https://github.com/jamesshore/quixote">Quixote</a>. Rather than comparing images visually, it looks at the code. Unlike Selenium, you don't have to assert specific styles, instead you can say something like "it should be centered" or "the left side should be 10px farther to the right of this other element".

blocks|key|414447|text|我们已经在一个大型的、以UI为主的项目上设置了单元测试，它工作得非常好！这也比看起来容易得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|414448|使用像getBoundingClientRect或getComputedStyle这样的简单工具，将其与配对以创建快速临时DOM树，您就可以开始工作了。我们已经编写了来减少使用进行测试时的样板，但是在任何测试设置中堆栈都是相似的。|offset|length|style|CODE|414449|昨天，我发表了一篇详细的博客文章，里面有一个简单的教程和关于我们的新工作流程以及它如何提高我们的生产力的现场示例：。|414450|entityMap|0|LINK|mutability|MUTABLE|url|http://devdocs.io/dom/element/getboundingclientrect|1|http://devdocs.io/dom/window/getcomputedstyle^0|0|3|L|P|G|3|L|0|P|G|1|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@$D|Z|E|10|1|11]|$D|12|E|13|1|14]]|A|$]]|$1|H|3|I|5|6|7|15|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

We’ve set up unit tests on a large, UI-heavy project and it worked wonderfully! It was also way easier than it looks.

Take simple tools like <a href="http://devdocs.io/dom/element/getboundingclientrect" rel="nofollow"><code>getBoundingClientRect</code></a> or <a href="http://devdocs.io/dom/window/getcomputedstyle" rel="nofollow"><code>getComputedStyle</code></a>, pair it with <a href="https://git.io/hyperscript" rel="nofollow">hyperscript</a> to create quick temporary DOM trees and you’re good to go. We’ve written <a href="https://git.io/tape-css" rel="nofollow">tape-css</a> to reduce boilerplate when testing with <a href="https://git.io/tape" rel="nofollow">tape</a>, but the stack will be similar in any test setup.

Yesterday I published a detailed blog post with a simple tutorial and live examples about our new workflow and how it boosted our productivity: <a href="http://tomek.wiszniewski.cc/how-css-unit-tests-helped-us-move-fast/" rel="nofollow">How CSS unit tests helped us move fast</a>.

blocks|key|3255956|text|单元测试CSS，取决于你的框架和你的CSS方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3255957|要问的问题：|3255958|在CSS中测试给定的类，例如Assert.IsNotNull|3255959|获取CSS属性并验证其属性。|3255960|首先，我会确定CSS文件是否存在，然后查找特定的类，然后在指定的类中查找属性。|3255961|在我的回归测试中，我遇到了一个缺失的类，并设法从之前的发现中立即修复了它。|3255962|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Unit Testing CSS, depends on your framework and your approach to CSS.

Questions to ask :

Testing for a given class in your CSS
 e.g, Assert.IsNotNull 

Get CSS property and verify its attributes.

Firstly, I would ascertain, if CSS file exist, then look for specific class then look for attributes inside the specified class.

I have experienced a missing class during my regression test and managed to fix it immediately from previous findings.

A few quick searches discovered that I'm obviously <a href="http://morethanseven.net/2008/10/13/unit-testing-css-looking-solution/" rel="noreferrer">not the</a> <a href="http://www.thoughtballoon.co.uk/blog/2008/11/11/example-css-style-guide-unit-testing-for-css" rel="noreferrer">first person</a> to have the thought "Can I unit test my CSS?". 

I'm wondering if anyone here has taken on CSS Unit Testing successfully? If you've tried and failed, or just have your own theories, please tell me why it (apparently) hasn't been done yet?

CSS Unit Testing

单元测试

回归测试

jQuery

几个快速搜索发现，我显然是单元测试的思想“我可以单元测试我的CSS?"。我想知道这里有没有人已经成功地进行了CSS单元测试？如果你尝试过但失败了，或者只是有你自己的理论，请告诉我为什么(显然)还没有完成？

问CSS单元测试
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问CSS单元测试EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问CSS单元测试
EN