Tag Info

New answers tagged

-2

The best answer I could find (and which also applies to statement coverage testing and other types of coverage testing) is given by this page from atollic.com "Why code coverage analysis?" More technically, code coverage analysis finds areas in your program that is not covered by your test cases, enabling you to create additional tests that cover ...


1

Observation of the robot is probably the most important test you can run. Don't let anyone tell you that anything short of a full integration test (which is what your observation is) is fully testing. However, there are also unit testing frameworks for Arduino. There are also Pseudo-Arduino boards. And there are also ways to do pseudo-object-oriented C, ...


1

If the code is already in production and has no tests for it, then by definition you cannot do TDD with it. At that point you have at least these alternatives: Discard the code and start again using TDD. This can obviously be time consuming, but judging from previous experience it would often have been faster than the other alternatives. Just use TDD for ...


-3

I'll be quite radical but please read this fully before criticising. In short: test-driven design is a kind of myth. It's impossible for implementation even for a new code unless all specifications are already fixed and won't change (that's classic "Waterfall" case but not a "Agile" one, opposed to the usually declared TDD application area). When it works ...


0

It's not always easy and sometimes you just have to be pragmatic and use integration tests or end-to-end tests to begin with until you have refactored code to be more testable. Perhaps try to refactor the class to use an interface instead of a concrete class and inject in the implementation during construction. Then use a mocking framework or roll your own ...


2

This is a very complex question, in a legacy systems designed without testability in mind probably there are a lot of coupling and this coupling make testing in isolation (unit testing) more difficult. I can give concrete answer if you ask a concrete question, with code and a concrete situation, but if you ask for general advice the best thing i can do is ...


2

If you want to test your code independently of NodeJS, create a service layer or repository layer that contains an API you can call on one side, and Node.JS calls on the other. You can use your stubs or mocks on the methods in that layer, or even swap out the entire implementation of the service layer if that works for you. What you test is the same as it ...


1

Maybe one relationship lies in the concept of Oracle described by Bertrand Meyer, author of Eiffel, in "Seven Principles of Software Testing". A test run is only useful if you can unambiguously determine whether it passed. The criterion is called a test oracle. If you have a few dozen or perhaps a few hundred tests, you might afford to examine the ...


2

Condition testing is a direct consequence of the fact that each if in your software creates a "bifurcation" (essentially breaking your code up into two separate bits of code), thereby increasing the overall cyclomatic complexity of your code. In order to get full code coverage in a white box testing scenario, you need to have some knowledge of the if ...


4

There are typically two reasons for worrying about performance/load testing, either the team has trouble writing simple algorithms or specific performance requirements are part of an SLA. The third reason is that members of your team just like to worry about performance, aka Premature Optimization. Performance tests should never be part of your unit ...


1

Ideally there should not be a difference. That is, different parts of model might be elaborated in more detail for test, others might be elaborated in more detail for development. However, the scenario in which the test team goes off to make its own sequence diagram which is ignored by the development team is problematic to say the least. A recipe for ...


0

My fuzzy answer is that sometimes having UI unit tests is a good idea, for some parts of the UI. In my experience: Often the people responsible for functional and integration testing are different people than those responsible for unit testing (typically, QA vs. Dev). As such, each may spot different areas (and have different blind spots) as to what ought ...


9

The criteria of "Is it currently being tested by this specific unit test?" If it's not being tested, yeah, stub it, mock it, fake it, set it to a hard known value, whatever. That way you know it's impact on the thing that's actually under test. Even though it's internal to your project and you control the source, it's external to the current thing you're ...


0

One thing I learned about dealing with legacy code which I did this for medium and big projects with > 1 million lines of code, it makes sense to use TDD here as well. But it is much harder to get your code there in tests. Normally legacy code bases doen't have any tests in place so fixing a bug and writing a unit test for it is a good starting point to ...


0

TDD shouldn't be used when some alternative approach is more appropriate. The key thing to remember is that the alternative approaches aren't so much manual testing, as things like: Write and review a detailed design document Produce a complete design in a CASE tool, press the 'generate code' button. Create a set of unit tested reusable components, ...


0

I try not to think of the assignment of a User Story or Bug as assigning sole responsibility to one developer. Try to think of it as assigning someone who is responsible for driving the effort required to resolve it. Anyone can be pulled in as necessary and could be potentially assigned a task to capture that effort. For larger teams that use Area Paths ...


0

Some cases I can think of when one might not want to to TDD are: minor changes to old systems that have no tests. minor changes to old systems that have no test framework. design and development of visual items and effects. tight deadlines and a disinclination to produce quality work.


7

Factors Limiting Industrial Adoption of Test Driven Development, a research paper from 2011, reviewed 9,462 papers on TDD, and included 48 studies as a basis for their research. The paper covers the topic of why TDD may not be used in depth, but for ease of reference, here's a summary: Development time: Development time could be considered a ...


3

I think it all comes down to a simple question: Does it have to work? If it does, then I would say it is best to do TDD, on the majority of cases. To me, the exceptions are very lightweight pieces of code. Weight the effort of manually testing every single procedural branch in the code. If this effort is smaller than that of writing automated tests, then ...


-1

It boils down to the simple fact that you have to decide which cases you need to cover. If you need to be sure of the database connection, you have to test it. Tests are separated in groups based on what they test (unit, integration and system), where only system tests would make real calls to a database (or other external services). Each type of test ...


1

The first and most important test of a component is to test the external interfaces. Write those tests first, and make sure they are comprehensive. Then add some more. Then review them, find out which cases are missing, and add them. Then add some more. Write lower level (i.e. class-as-unit) tests only when: your higher-level (i.e. component-as-unit) ...


1

I see unit tests as routines that test pieces of code that are in a code base that you manage. Mocking and stubbing helps focus only on the flow and logic of your code, which is what you are testing in your unit tests. Whether or not an outside service like a database (which is not inherently part of your code) actually works is not important for unit ...


0

So should I have a subset of tests that do test such connectivity at least and some simple operations, for example creating a record in the primary transaction detail table, even if most of the foreign keys are stubbed out? Unit tests can and should never replace integration tests. That is, when testing the data layer you should always use integration ...


3

Ask yourself: what kind of performance tests do you have, and how often do you need them to be run? Tests for the "daily use"? Then make them part of your unit tests. Just in the QA cycle of every release/deployment? Keep them as part of your integration tests (assumed those tests are run for every release/deployment). Tests for an isolated part of your ...


1

This is a pretty common question to people starting to learn TDD. I don't know if that's your case, but the logic you can follow is the same. First, forget the word "unit" for a moment. Think about how you would approach the development of the same package from ground zero and test-first. You can't start by testing "a class only" or "a method only" because ...


4

Unit testing is the lowest level of testing, but that means only that it is the lowest level you do, not the lowest level you could theoretically do. If you test at the class level, you could test at the method level, using an appropriate test tool to get at private members. But if you test at the method level, you could test at the statement level, using an ...


0

Unit testing is like inductive reasoning. You ensure that the small piece n is well-behaved, and then can trust that as you build up the system, each n + 1 piece is also well-behaved. In your case, I would isolate as many of the 5-6 classes in individual testing to make sure that each one is doing what it should. (That has an extra benefit of speeding up ...


4

My own answer/realization: From fixing various errors while refactoring I am realizing that I wouldn't have done the code moves as easily without having tests. Tests alert me of behavioral/functional "diffs" that I introduce by changing my code. You don't have to be hyper aware when you have good tests in place. You can edit your code in a more relaxed ...


1

Almost all statically typed language have runtime type and method discovery. The main exception is C/C++. In the .NET world, reflection and attributes provide a particularly rich environment for test discovery and management, which both Visual Studio and NUnit utilise. The Java world has something similar, see JUnit. Those are the "big three". Scala, ...


0

Golang handles this by using the parser module to parse the test files, and then generating a new program which runs the test files, compiling that program, and executing it: https://code.google.com/p/go/source/browse/src/cmd/go/test.go#1022


4

Many statically-typed languages still use reflection for this purpose - for example, JUnit3 calls all methods named testWhatever, and go test looks for methods named TestWhatever() inside any _test.go files. JUnit4 appears to rely on Java's "annotations" system -- it supports a @Test annotation which is available at runtime and is used for test discovery ...


1

In my experience, the biggest hurdle to writing tests is in answering the question "how do I write a test?". If it is difficult or unclear, people won't do it. So, if you make it clear, and make it not-difficult, people will start doing it. So, how do you do that? You pick an existing framework, install it such that anyone can use it, and start using it. ...


2

You are talking about performance, which is essentially an Non Functional Requirement. My view is that most of these are for the whole system. A user is never going to say "I want the WidgetListCollection class to return a widget within 20 nanoseconds" -- he might say "I want a list of all products on my screen within 1.5 seconds". The only way to ...


1

How do people/companies handle this type of test? There are many kind of testing, but your interests are unit and functional : unit tests - needs to be very fast, in order to be execute on every change in the code. Their purpose is to test modules. functional tests - they are similar to unit tests, except they do not need to be fast. They are ...


0

The problem its the question itself, you don't need to test all the "methdos" or all the "classes" you need to test all the features of your systems. Its key thinking of terms of features/behaviors instead of thinking in terms of methods and classes. Of course a method its here for providing support for one or more features, at the end all your code its ...


2

There are few types of unit testing: State based. You act and then assert against state of the object. E.g. I make a deposit. I then check to see if balance has increased. Return value based. You act and assert against return value. Interaction based. You verify that your object called another object. This seems to be what you are doing in your example. ...


1

When faced with a philosophical quesion, drop back to the driving requirements. Is your goal to produce reasonably reliable software at a competitive cost? Or is it to produce software of the highest possible reliability almost regardless of cost? Up to a point, the two goals of quality and development speed/cost align: you spend less time writing tests ...


4

Strictly speaking, you can't. You could mock the APIs, but you'd only be testing that you're calling them a certain way in the implementation. That doesn't prove the implementation is correct - if you make incorrect assumptions in the implementation, you're going to duplicate those mistakes in the tests. Moreover, your tests will be brittle, because you're ...


0

One strategy I see used is to group your tests by duration. Let's say you've got 300 tests. 100 of them run in 30 seconds or less. 100 of them run 30 seconds - 60 seconds, and 100 of them run longer than that (maybe do a little statistical analysis to break them into 3 or 4 groups). If you structure your test execution process (for example, using tagging ...


4

There are several approaches to attacking the time bloat of automated testing. Some of the approaches such as running multiple virtual environments and running the tests in parallel, and reducing the scope of what is actually tested may not not suitable for your workload, but are worth mentioning as possible strategies for other readers in the future. One ...


-1

Which automated testing tool are you using? This will significantly affect answers. As for shortcuts yes you can trim down some of your tests. e.g. If your first steps are always launching, logging in, navigating to module X... querying for "thing-a-ma-bobs" then running 12 scripts that do something with one. you can split your tests up so that you have ...


4

I find myself writing code for hours, even days without running the compiler for anything but an occasional syntax check. Hours to days - that's a clear sign that you miss the ability to break down your code into smaller chunks which can be verified and tested on their own. You should definitely work on that. I tend to write bigger chunks of code ...


1

Is it possible? Sure it is. Is it recommended? That's a tougher question - automated tests are created to validate the functionality of your application. Generic testing can only test generic functionality. I can see two main use-cases where you might find yourself contemplating on generic testing: Testing applications which use the same boilerplate ...



Top 50 recent answers are included