Tag Info

Hot answers tagged

17

When your dev team and your QA team don't not talk to each other, there is a certain risk that some tests are unnecessarily done twice, and some others are forgotten. One worst case scenario is when your dev team has implemented some nice automatic integration tests, which run in a few minutes or hours, and your QA people tests the same things manually, ...


15

Testing team (the so called QA team in some organization) insists that the dev team should share their (Dev team's) test cases with them. Sure, QA should have a general understanding of what is covered by unit/integration tests, and what is not. Their arguments are Dev test cases are the starting point for the QA testing. ...even if their ...


14

You should write your unit tests very near to when you write your code. "Timely" is one of the five core tenets of unit testing per Clean Code. There's even an approach that advocates writing your unit tests before your code. It's called Test Driven or Test First Development, depending on who you're talking to. In my experience, it doesn't matter too much ...


7

Am I doing it is right? If not what exactly I have to change It's hard to say just from that short description, but I suspect that, no, you are not doing it right. Note: I am not saying that what you are doing doesn't work or is in some way bad, but you are not doing TDD. The middle "D" means "Driven", the tests drive everything, the development ...


5

You describe your development approach as a "top-down-only" process - you start from a higher abstraction level and go more and more into the details. TDD, at least in the form as it is popular, is a "bottom-up" technique. And for someone who is working mostly "top-down" it can be indeed very unusal to work "bottom-up". So, how can you bring more "TDD" ...


5

Because hitting a database is slow, requires an elaborate environment set up just right in order to work, and spends most time in code not written by you. A unit test is supposed to test your code, not Oracle's code. 2./3. No, you don't replace mocked things with real things. You leave mocked collaborators in your testing code, and then you don't ship ...


4

In a modern software architecture the intent is that the tests not only test the code but they do so in a way that documents their functionality. This documentation of what the code does (in addition to what it is intended to do in the specs) is useful for QA'ers to better understand the intent of the code and also whether it matches the requirements. It ...


4

When you are testing a unit of code (say a single method or class), you want to only test that unit and have no other dependencies (with possibly unknown state). If you don't use mocks in unit tests, you are putting yourself in a position of uncertainty - if a class your method/class depends on changes, it can break your test even though your code has not ...


4

TDD is primarily an implementation technique, so it works as orthogonal as writing other code to the "graphical" design techniques you mentioned. (If the latter techniques are used in all software companies, for all kind of professional software, is a completely different question.) When you have UML diagrams on the abstraction level of your public class ...


4

You can start unit testing as soon as you have a notion of a class you want to create. The meaning of "unit" will depend on the programming language. For example, suppose you want to create a function to parse roman numerals. You might start with this unit test: public class RomanTest { public void iEquals1() { assertEquals(1, ...


4

A large part of this mass of tests is for their collection implementations. They've written generic tests that exhaustively test the collection interfaces, and this generates a suite per implementation. See, for example, classes called CollectionAddAllTester, ListIndexOfTester. This is all backed by a library called testlib, which ships as part of Guava. ...


3

Am I doing it is right? If not what exactly I have to change You're doing just fine. Is there any way you can identify whether test you have written are enough? Yes, use a test/code coverage tool. Martin Fowler offers some good advice on test coverage. Is it good practice to writing test for very simple functionality which might be equivalent ...


2

I had a similar problem with my code with global state via singelton. As @Thomas-Junk-s and @SHODAN-s comment suggested i refactored my code to make the static global state non-static through constructor Dependency injection. Example original code public static class Global { public static int getSomeGlobalState() {...} } public class MyClass { ...


2

Writing tests first is a completely different approach to writing software. Tests are not only a tool of proper code functionality verification (they all pass) but the force that defines the design. While test coverage might be a useful metric, it must not be the goal in itself - the goal of TDD is not to get to a good % of code coverage, but to think about ...


1

My first reaction of this question is “it depends”. It depends on what you mean by “development team test cases”. If you have only unit tests (white-box test); QA Team (integration and system test) could not leverage your test-cases. Unit test are only there to verify your unit, which solely don’t satisfy a requirement (mostly). White-box testing ...


1

You should start writing your tests when you start writing your code. The important part is that any code you write is driven by a unit-test; instead of stepping through the code manually, do it with a test. It doesn't take that much more work to write a test than it does to step through the code. By writing a test to drive your newly written code, you ...



Only top voted, non community-wiki answers of a minimum length are eligible