Tag Info

New answers tagged

0

IMHO TDD is primarily a whitebox technique, and, I think it is more an implementation technique than a testing technique. It is applied by the developer who writes the code in very small iterations "write test, write code, refactor", so by someone who knows exactly the already implemented parts, and the missing parts of the "subject under test". Whenever ...


0

If the executor is a singleton then you should replace the executor returned by its getInstance() (or stored in the static INSTANCE field) with your mocking framework until you can put DI in place. That way you can monitor the task queue and be know when no more tasks are pending completion.


2

Yes selenium can be used to automate the manual interaction steps. It's intended to be used against web browsers and it's widely used and implemented. However this is only half of the puzzle. Selenium is the core technology in browser automation tools, APIs and frameworks. To actually USE selenium you are going to need to pick an actual implementation. ...


1

What you describe is a thinly-veiled coating over Singleton. Essentially, you have global state and are trying to funnel access through that one class. The fact that the interface is static instead of object-owned is the "coating" I referred to. This is one of the few acceptable uses for Singleton. While that pattern is often misapplied, providing a single ...


1

Personally, I would not like to live with static methods to keep consistency across a code base. The advantages, whether you consider them "real" or not, of injecting the settings lie, as always in the freedom gained and the disadvantages avoided. I'd always prefer to inject a settings instance as it ties you down the least and doesn't force you to use a ...


0

Set some variable (accessible to your unit test) when the event occurs. If the event doesn't occur, the variable doesn't get set; you can check for that in your unit test.


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


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

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


1

When it comes to this sort of hard to test algorithm I would go for the TDD, where you build the algorithm based on tests, TDD in short, write the test see it's failing modify the code make sure all tests are passing refactor and repeat the cycle, In this particular situation, First test would be, single node graph where algorithm should not return ...


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

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


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

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


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


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


1

This is the kind of thing you definitely need to integration test, as real-world file systems have all kind of strange behavior (like the way Windows won't allow deleting a file if any process, including the deleter, has it open). So the TDD approach is to write the integration test first (TDD, strictly speaking, doesn't have distinct concepts of 'unit ...


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


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


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


8

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


0

The answer like most things is "it depends". If you want to unit-test the functionality in doSomethingImportantUsingDependency, then you will need to be able to inject the dependency. However, if all that doSomethingImportantUsingDependency does is some property mapping from the result of your database call, then it would be pragmatic to not bother. If ...


10

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


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


1

It may take you longer to write code complete with unit tests. In fact it probably will. What makes it a more productive way of working for the organisation as a whole is all the things that don't happen further down the line, and in particular don't happen to other people, when you have your code armed with a full battery of tests. Fewer manual testers ...


0

ETL can be done with TDD and tests pretty similarly to most projects, i.e. write a test that fails (red) fix the failure (green) make the code performent & maintainable (refactor) So for ETL that might be: write a script to load 1 record fail (no data source defined) define source [green] no refactor need write a test to load 1 record with only 1 ...


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


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


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


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


0

After a few more years of coding and working on projects I'll provide an answer to my own question. Yes, you should write unit tests. End to end tests are harder to write and brittle especially if they're relying on UI components. If you're using a framework like Django or Rails (or your own custom classes) you should have a form class that will handle ...


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


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


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


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


0

I've worked on and continue to work on large scale api projects and I've never used the BindAttribute. I would say with this code remove it completely, it will still work and it will remove the error prone strings in the attribute. Personally and from my experiences you shouldn't pass out your data entities from an api endpoint. We use view models, but ...



Top 50 recent answers are included