There are a few options as described in the testing flags docs: go clean -testcache: expires all test results use non-cacheable flags on your test run. The idiomatic way is to use -count=1 That said, changes in your code or test code will invalidate the cached test results (there’s extended logic when using local files … Read more
The Maven build lifecycle now includes the “integration-test” phase for running integration tests, which are run separately from the unit tests run during the “test” phase. It runs after “package”, so if you run “mvn verify”, “mvn install”, or “mvn deploy”, integration tests will be run along the way. By default, integration-test runs test classes … Read more
I recommend using type instead of classifier (see also: classifier). It tells Maven a bit more explicitly what you are doing (and I’ve found that m2eclipse and q4e both like it better). <dependency> <groupId>com.myco.app</groupId> <artifactId>foo</artifactId> <version>1.0-SNAPSHOT</version> <type>test-jar</type> <scope>test</scope> </dependency>
Assuming you are testing via mocha, you have to run your tests using the mocha command instead of the node executable. So if you haven’t already, make sure you do npm install mocha -g. Then just run mocha in your project’s root directory.
I did something like that: const element = document.getElementById(‘div’); if (element.getAttribute(‘listener’) !== ‘true’) { element.addEventListener(‘click’, function (e) { const elementClicked = e.target; elementClicked.setAttribute(‘listener’, ‘true’); console.log(‘event has been attached’); }); } Creating a special attribute for an element when the listener is attached and then checking if it exists.
If you want to do “real” TDD (read: test first with the red, green, refactor steps) then you also have to start using mocks/stubs, when you want to test integration points. When you start using mocks, after a while, you will want to start using Dependency Injection (DI) and a Inversion of Control (IoC) container. … Read more
You’re checking the wrong method. Moq requires that you Setup (and then optionally Verify) the method in the dependency class. You should be doing something more like this: class MyClassTest { [TestMethod] public void MyMethodTest() { string action = “test”; Mock<SomeClass> mockSomeClass = new Mock<SomeClass>(); mockSomeClass.Setup(mock => mock.DoSomething()); MyClass myClass = new MyClass(mockSomeClass.Object); myClass.MyMethod(action); // … Read more
Sounds like a job for XMLUnit http://www.xmlunit.org/ https://github.com/xmlunit Example: public class SomeTest extends XMLTestCase { @Test public void test() { String xml1 = … String xml2 = … XMLUnit.setIgnoreWhitespace(true); // ignore whitespace differences // can also compare xml Documents, InputSources, Readers, Diffs assertXMLEqual(xml1, xml2); // assertXMLEquals comes from XMLTestCase } }
For macOS, there is the Network Link Conditioner that simulates configurable bandwidth, latency, and packet loss. It is contained in the Additional Tools for Xcode package.
Another option is to use https://github.com/spulec/freezegun/ Install it: pip install freezegun And use it: from freezegun import freeze_time @freeze_time(“2012-01-01”) def test_something(): from datetime import datetime print(datetime.now()) # 2012-01-01 00:00:00 from datetime import date print(date.today()) # 2012-01-01 It also affects other datetime calls in method calls from other modules: other_module.py: from datetime import datetime def other_method(): … Read more