Tag Info

New answers tagged

0

Part of BDD is applying the 3 Amigos approach where the stakeholders collaborate to produce the acceptance criteria. QA/Dev can write the step code to make scenarios execute as acceptance tests. Where is the value of QA to execute manually the same acceptance tests that a BDD tool will execute automatically? The value add of QA is to validate those ...


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 ...


-4

Forget the unit testing. Write and test yourself by being a user. deliberately try to break what you wrote even to the point of doing things you would never do but someone else might. This way you will discover things you could not foresee when writing unit tests. Your unit tests will, like your code make sense, but users are free from such restrictions. ...


3

Just because the programming language abstracts the branches away into a boolean expression, doesn't mean they aren't there. If you looked at what actually gets executed, it looks like this: +-----------+ |is A true? +------------------+ +----+------+ | | | ...


1

In the example you use, there are four (4) possible paths of execution, and hence four (4) tests that must be performed. They may be enumerated as follows, where x denotes "don't care": 1xx: A is true, don't care about B and C - then path 01x: A is false, B is true, don't care about C - then path 001: A and B are false, C is true - then path 000: A, B, ...


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 ...


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, ...


0

Start early! Why wait? Once your system is more complex than a simple "Hello, World!" application, you can start writing unit tests to ensure that what you've coded works correctly. If you use a tool like maven for your builds, you can have the tests run with every build so you should know pretty quickly if newly written code has issues with existing code.


-1

I would use the Test-Driven Development method if I were you. It's pretty straightforward, you unit test the method before they exist, run the test. They will fail. You will then fix them by making your methods work.


1

Why does TDD work? It doesn't. Clarification: automated tests are better than no tests. However I personally think that most of unit tests are waste because they usually tautological (i.e. says things obvious from actual code under test) and it can't be easily proven that they consistent, not redundant and cover all border cases (where errors usually ...


11

It is reasonable to negotiate for having automated test scripts as a deliverable, but it is not reasonable to expect to get them if they were not explicitly included in the (initial) agreement. Unless the project is explicitly being executed under a development method that implies automated testing, such as TDD, or you negotiated for delivery of the scripts ...


9

No. That metric displays a fundamental misunderstanding of both testing and reliability. Testing can only ever prove the presence of bugs, but never the absence. A test suite demonstrates that a system is capable of functioning as expected (incl. known failure modes), but except in the most simplest cases can never prove that it will always work as ...


2

Here's a mostly flawless setup for testing your websites : Cross-browser compatibility : A good resource prior to implementing your solution is to check Can I Use?, which has compatibility for all the HTML5/CSS3/JS/SVG, etc... Every time you implement a new feature, test your site in Chrome, Firefox, IE, Safari and Opera (in order of importance). They're ...



Top 50 recent answers are included