Geek Answers Handbook

Enter code that is difficult to execute unit test

In an interview I was asked the question: "How to make the code difficult for unit testing?" I ended up muttering something about writing tightly coupled code. Can someone please tell me what is the correct answer / approach for this question?

+4
source share
5 answers

Take a look at the Mishko Guide: Writing test code , enter so many of these shortcomings into your code, and you will get unverified code.

For instance:

  • do as much as possible in constructors, run threads, use loops and ifs
  • break the law of Demeter by creating a long chain of method calls
  • use singletons everywhere, never ask for dependencies, look for them in a static provider
  • create god classes with 2k lines of code
+4
source

Well, some answers may be

  • Code that accesses the database
  • Code that behaves in accordance with the datetime system
  • Code that executes more than one functionality in the same method (Unit)
  • Code with a lot of code behavior that depends on another code without reading

and in genral, any code where it’s difficult / impossible to simulate the environment in order to allow it to behave as it should be tested.

+2
source
  • Creating the dependencies required by the class using the new operator will be enough! This means tightly coupled code, which is your answer.
  • Code that does not follow SOLID principles .

Thus, in the test you will not be able to use Mock objects when creating dependencies yourself and hardcoding relationships.

When nesting dependencies, you can use polymorphic behavior, so a class that calls a method on the dependencies passed to it in the constructor or method does not need to know a specific type. Thus, when testing, you can pass the layout of the object, and you can easily test your class.

Misko Writing test code explains how we can write code that cannot be tested and how to solve it.

Example (JAVA):

 //hard to unit test this code as testing class A also requires that ClassB should work properly //What is ClassB does some I/O or DB operations. This makes unit test a integration test class classA{ ClassB b = new ClassB(); //Creating concrete dependencies } interface B{ //implemented by Class B and your mock class that you create for testing } class ClassA{ private B b; //Here you can use mocking framework or create a mock class yourself and pass that as argument //So the mock class will not do any DB or I/O and makes this unit test public classA(B b){ this.b = b; } }
+1
source

That is a good answer. Closely coupled code is extremely difficult for a unit test (and probably should not be tested for one), it should be reinstalled first), because by definition unit tests can only test a specific unit. All calls to databases or other system components should be avoided with Unit Tests, because they violate this.

With that said, you can also mention that integration tests are good for testing larger relationships of code or code with dependencies, or even action-based actions. You can build an integration test suite for something like testing your REST API, which has many dependencies and even crosses many technologies and several programming languages.

Also, without thinking through the design or using a decent design template, it can lead to extremely complex or dependent code, which can be difficult or impossible for the unit test without repeated factorization or rewriting. You can then talk about TDD (Test Driven Development http://en.wikipedia.org/wiki/Test-driven_development ) or BDD (Behavioral Driven Development http://en.wikipedia.org/wiki/Behavior-driven_development ), which makes you start by developing a test suite and working from there.

+1
source

Code that is hard to separate - multiple responsibilities are shared among several classes, but not a single class that bears any responsibility

Code that is very difficult to view - try the middle state machine if / then / else bomb 500 lines.

Codex, which applies very strongly to a given field, is an obvious example of mathematics. Take the Fourier transform function and add one unit test, which shows that all zeros are converted to all zeros. 100% coverage, but nothing really tested at all.

Code that is strongly related to external dependencies that are related.

Code with huge interfaces that perform several actions.

0
source

More articles:


All Articles