In Debugging Microsoft .NET 2.0 Applications John Robbins has a big section on assertions. His main points are: Assert liberally. You can never have too many assertions. Assertions don’t replace exceptions. Exceptions cover the things your code demands; assertions cover the things it assumes. A well-written assertion can tell you not just what happened and … Read more
Assertions (by way of the assert keyword) were added in Java 1.4. They are used to verify the correctness of an invariant in the code. They should never be triggered in production code, and are indicative of a bug or misuse of a code path. They can be activated at run-time by way of the … Read more
The soft assertion concept is pretty cool, and you can add it with minimal implementation to Cypress const jsonAssertion = require(“soft-assert”) it(‘asserts several times and only fails at the end’, () => { jsonAssertion.softAssert(10, 12, “expected actual mismatch”); // some more assertions, not causing a failure jsonAssertion.softAssertAll(); // Now fail the test if above fails … Read more
Using JUnit 4.4 you can use assertThat() together with the Hamcrest code (don’t worry, it’s shipped with JUnit, no need for an extra .jar) to produce complex self-describing asserts including ones that operate on collections: import static org.junit.Assert.assertThat; import static org.junit.matchers.JUnitMatchers.*; import static org.hamcrest.CoreMatchers.*; List<String> l = Arrays.asList(“foo”, “bar”); assertThat(l, hasItems(“foo”, “bar”)); assertThat(l, not(hasItem((String) null))); … Read more
I suggest you to use soft assertions, which are provided in TestNg natively package automation.tests; import org.testng.asserts.Assertion; import org.testng.asserts.SoftAssert; public class MyTest { private Assertion hardAssert = new Assertion(); private SoftAssert softAssert = new SoftAssert(); } @Test public void testForSoftAssertionFailure() { softAssert.assertTrue(false); softAssert.assertEquals(1, 2); softAssert.assertAll(); } Source: http://rameshbaskar.wordpress.com/2013/09/11/soft-assertions-using-testng/
If you need to switch on the type of the outer interface{} you wont need reflection. switch x.(type){ case int: dosomething() } …but if you need to switch on the type of the attributes in an interface then you can do this: s := reflect.ValueOf(x) for i:=0; i<s.NumValues; i++{ switch s.Field(i).Interface().(type){ case int: dosomething() } … Read more
As you mention that you use Hamcrest, So I would pick one of the collection Matchers import static org.hamcrest.collection.IsIterableContainingInAnyOrder.containsInAnyOrder; import static org.junit.Assert.assertThat; public class CompareListTest { @Test public void compareList() { List<String> expected = Arrays.asList(“String A”, “String B”); List<String> actual = Arrays.asList(“String B”, “String A”); assertThat(“List equality without order”, actual, containsInAnyOrder(expected.toArray())); } }
Out of my mind (list may be incomplete, and is too long to fit in a comment), I would say: use exceptions when checking parameters passed to public or protected methods and constructors use exceptions when interacting with the user or when you expect the client code to recover from an exceptional situation use exceptions … Read more
99.9% likely that you have corrupted memory (over- or under-flowed a buffer, wrote to a pointer after it was freed, called free twice on the same pointer, etc.) Run your code under Valgrind to see where your program did something incorrect.
If you launch your program with -enableassertions (or -ea for short) then this statement assert cond; is equivalent to if (!cond) throw new AssertionError(); If you launch your program without this option, the assert statement will have no effect. For example, assert d >= 0 && d <= s.length();, as posted in your question, is … Read more