Tag Info

Hot answers tagged

23

The two are different things, and in fact much more different in practice than they would be in theory. A formal correctness proof proves something about the behaviour of an algorithm. For instance, it might investigate the invariants applying to the data as it is transformed by a sorting algorithm, and prove that if the algorithm terminates, every element ...


13

If you first test things manually through a user interface, until you do not find any bugs any more, and write unit tests afterwards, it is not very surprising that those unit tests do not reveal many bugs. You are probably just automating things you already have done manually, but do not code many test cases which were not already part of the manual tests. ...


12

To answer the specific question, it's absolutely possible that grouping tests into multiple classes is a good decision, event when the class under test is well designed. Unit test code is like any other code: it should follow good design principles (DRY, GRASP, KISS, SOLID, YAGNI, etc). Because the logic that makes up test code is often simpler than domain ...


11

One thing to remember about testing is that you're going to do it either way. Whether you're printing application variables to the screen, using a debugger to inspect your application's state or just visually verifying the final output of the application's input, at the end of the day, you'll have spent quite a bit of time commenting out code, perhaps ...


9

In C# it is trivial to provide optional dependency injection without coupling yourself to your dependency too tightly: public class SomeOtherClass { private readonly ISomeClass _someClass; public SomeOtherClass(ISomeClass dependency = null) { _someClass = dependency ?? new SomeClass(); } } (or you can make the constructors explicit if ...


7

There's a development principle along the lines of DRY and SOLID called YAGNI that is designed to help streamline your development efforts in getting things done and not getting paralysed with indecision over what to do. If you later find that you need to enhance your class, then you will. YAGNI says not to worry so much over it now 'cos you probably won't ...


7

Why are my unit tests so expensive? For the same reason divorce is so expensive: It is worth it. In my experience (bizdev, C#/Java over more than a decade now), writing unit tests for code takes about half the time as writing the code itself - so 33% of your total coding time. Some things will be more. Some things will be less. When you're just ...


7

There is no precise, universally accepted definition of "formal method". However, most definitions imply some form of mathematical rigour, formalism or proof, none of which a unit test provides. A unit test is simply "try it out and see if it works in this one single specific case", whereas formal methods try to prove that "it always works in every case ...


6

It is almost of no importance how your unit tests are organized compared to having them in the first place. A module or class of business code is something you have to understand as a unit and develop further. That's the main reason we strive to make it coherent, easy to grasp as a whole, etc. A test suite is only a collection of cases that must all pass; ...


5

In their book Growing Object-Oriented Software, Guided by Tests, Steve Freeman and Nat Pryce tackle this very issue. I do recommend that as a worthy read, since it's full of interesting examples and I'll probably just misquote, anyway. Rephrasing, they argue that instead of mocking the external API you have no control over, you should create a layer of ...


5

No testing whatsoever is going to be able to be sufficient in this case, not even tons of real world data or fuzzing. A 100% code coverage, or even 100% path coverage is insufficient to test recursive functions. Either the recursive function stands up to a formal proof (shouldn't be that difficult in this case), or it doesn't. If the code is too intertwined ...


4

If you do not apply DI as long as you do not really need it (not even for unit testing), nothing bad will happen. The code does not become error prone, "overly complicated", or hard to maintain. And if you decide to refactor the dependency out later, it will most probably not be much more effort than doing it now. That's a case where the YAGNI principle ...


4

We keep thinking that we have all the tricky ones covered and then we realise that a certain structure causes problems we hadn't considered before. Testing every tricky that we can think of is what we are doing. That sounds like a good start. I guess you already tried to apply some classic techniques like boundary value analysis or equivalence ...


4

1. Randomized test generation Write an algorithm that generates graphs, have it generate a few hundred (or more) random graphs and throw each at your algorithm. Keep the random seed of the graphs that cause interesting failures and add those as unit tests. 2. Hard-code tricky parts Some graphs structures that you know are tricky you can code in right ...


3

Absolute nonsense. A few thoughts: You should not take OOP and it's principles too seriously. Many times functional or other software paradigms make more sense. Though the objects thing is cool... thinking in concrete components and all that. Testing, and specifically Unit Testing is meant to serve the project, verify it's design, and assure its ...


3

If that common behavior sees frequent use, it will admittedly be executed multiple times during tests for each of the subclasses, but so will it at runtime in production, there's nothing wrong with it. However, that doesn't mean you should specifically test the common logic multiple times. Concrete/abstract superclass If the superclass is not abstract and ...


3

Put the tests in one file. Typically for every class file I would have a test file. Usually append "Tests" to the file name. For example, if there is a class called "Foo" there would be a corresponding "FooTests" file. This way for every code file there is a 1 to 1 relationship between code file and the test file. This provides consistency and makes ...


3

If we say that definition of bad practice in software development is anything that doesn't help you cope with and encapsulate change then I would say not keeping your classes and tests in one to one relationship is bad practice. It is a code smell that might arise because of the things mentioned below. Obviously there are exceptions just like with anything ...


3

You cannot jump directly from "idea" to "implementation". Good example is the "V model" : You start at high level go lower and you write tests on each level. And each level gets more specific in both implementation and testing. For example you write an acceptance test that says that you should be able to add a customer. This results in you writing an ...


3

You could try doing a topological sort and seeing if it succeeds. If it doesn't, then you have at least one cycle.


3

Ideally, you want both unit tests (which test individual functions) and integration tests (which test all the functions together), not just one or the other. You will also need a way to mock out the web service you're calling so that these tests don't depend on it. To directly address a few of the sub-questions: So is correct to create a big test that ...


2

My understanding of the problem, as originally stated and then updated by comments under Macke's reply, includes the following: 1) both edge types (dependencies and conflicts) are directed; 2) if two nodes are connected by one edge, they must not be connected by another, even if it is of the other type or in reverse; 3) if a path between two nodes can be ...


2

I don't know ASP.NET, but generally your dependencies would be on interfaces, and in your unit tests you provide mock, stub, or fake implementations of those interfaces. This lets you test your class in isolation, since the only code under test is the class itself plus your "skeleton" dependencies.


2

You stumbled on one of the Bigger problems that tends to get swept under the rug in unit testing/TDD discussions. Well designed code from an object oriented perspective is generally hard to unit test, code that is easy to write unit tests for usually is compromising some paradigms of object oriented design. Most approaches to unit testing tend to drive ...


2

I would start with eliminating the duplicated code first by building a generic creation service, something along the lines of class GenericCreatorService<T> { UnitOfWorkFactory _unitOfWorkFactory; // ... public T Create(Func<T,UnitOfWork> func) { using (var unitOfWork = ...


2

It sounds like the logic in performOperationsOnData() could justifiably be put in its own class. It looks like the class with the writeToDatabase(data) method is currently responsible for too much. It is orchestrating your Business Logic and Data Persistence Logic. Orchestrating is fine, as long as that is the class' only responsibility. So, here's how I ...


2

In order to test a method which accepts no arguments and returns no results you have to fiddle with the state that it works on, invoke it, and then examine the state that it modified by side-effect. I would strongly advice against doing that, and if that's how your top-level method has to be, then it is untestable as far as I am concerned. (Not objectively ...


1

The key is to test the intention of your code. This way even if you refactor the way your intention is being implemented you will still be able to have valid unit test because it is still the same intention. As you have mentioned yourself, if you have limited resources, then do what is most important and that would be business logic. Also don't forget ...


1

Inject the three Creator-classes and test the calls to them by unittesting the QuickOrderService. This keeps the tests on the relevant classes. Also, you might not need to haul the unitOfWork around. The implementation of Create could be changed to simply create a new transaction if none exists and otherwise return the existing transaction. This could keep ...


1

The type of unit testing you need to do to find bugs in existing mostly-working code is very different from the type used as a scaffold while creating or modifying the code. Only the latter is TDD/BDD. And, as it is somewhat newer, it tends to be the one that gets discussed in articles and blogs. Sometimes to the point where people get the impression that ...



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