Skip to content

Improvements to the unit tests directory #1111

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jul 18, 2017

Conversation

thk123
Copy link
Contributor

@thk123 thk123 commented Jul 10, 2017

I developed some utilities and fixed the Makefile for the unit directory. Rather than wait for that work to make its way to master, here are those improvements as they may be useful to others.

Would like some feedback on the directory structure - I wanted to keep utility code separate from the unit tests themselves. If people agree, I can add this to the coding standard.

@thk123 thk123 force-pushed the feature/unit-test-utility branch from dc1c7ed to 3a0f1bd Compare July 10, 2017 13:59
/// \param name: The name of the symbol.
/// \param type: The type of the symbol.
/// \return The symbol that has been created.
symbolt symbol_table_utilt::create_basic_symbol(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this make for a good constructor in symbolt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am happy to do this, but reasons why I didn't:

  • I thought it was a bit of an ad-hoc collection of flags that seems very useful when you want succinct tests, but not in general.
  • I don't understand all the flags in symbolt. I don't think this is a problem for tests, but seems more risky to introduce into the general codebase (someone might see this constructor, use it but in some unrelated part of the code, the missing flag could cause some nasty problems (not an issue with unit tests since only test isolated sections of the code).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take a look at various *_symbolt classes defined in symbol.h - I'd see nothing wrong in adding one more, which really must be a useful one as otherwise you wouldn't have factored it out into a new function. (This would also address the namespace discussion in this PR.)


/// \file
/// Helper functions for requiring specific expressions
/// If the expression is of the wrong type, through a CATCH exception
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

through -> throw

Copy link
Contributor

@reuk reuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Not sure about the namespace-esque usage of a class. I would prefer to use a proper namespace, as this code has confusing/misleading semantics.


#include <util/symbol.h>

class symbol_table_utilt
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure this should be a namespace.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're quite right - @peterschrammel would this be an acceptable use of a namespace?

@thk123 thk123 force-pushed the feature/unit-test-utility branch 2 times, most recently from 8e627a0 to 02fe8bd Compare July 10, 2017 16:19
@thk123
Copy link
Contributor Author

thk123 commented Jul 10, 2017

@tautschnig Added as an additional constructor to auxilary_symbolt as it had the flags I needed.

@reuk This "resolves" the issue of namespace vs class.

@reuk
Copy link
Contributor

reuk commented Jul 10, 2017

Sorry to be awkward but I think require_exprt should probably be a namespace too.

@tautschnig
Copy link
Collaborator

Sorry to be awkward but I think require_exprt should probably be a namespace too.

As much as I'd otherwise argue against namespaces: unit tests may be a good use of them to separate out code that is exclusively of use for testing purposes.


#include <util/std_expr.h>

class require_exprt
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@peterschrammel would it be OK as suggested by @reuk for me to make this into a namespace, I know they are forbidden by coding standard but I don't really understand why.

@thk123
Copy link
Contributor Author

thk123 commented Jul 10, 2017

As discussed in #1070 rather than LIBS it should be OBJ which will mean the dependency doesn't have to be manually managed. It also will fix the rebuild issue since already depends on OBJ. Will update this PR accordingly.

@thk123 thk123 force-pushed the feature/unit-test-utility branch from 02fe8bd to ddb728f Compare July 10, 2017 17:17
@thk123
Copy link
Contributor Author

thk123 commented Jul 10, 2017

@reuk @peterschrammel @tautschnig I have added a commit swapping require_exprt to be a namespace, I can either squash it or drop it once the decision is made.

Copy link
Member

@peterschrammel peterschrammel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise looks good to me.


#include <util/std_expr.h>

namespace require_exprt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure the t suffix is useful then.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requires a nolint or a change in the linting rules.

@thk123
Copy link
Contributor Author

thk123 commented Jul 14, 2017

@peterschrammel Changes applied and namespace change squashed.

@tautschnig
Copy link
Collaborator

@thk123 Would it be possible to rebase this one and make all CI tests pass? It seems the need for linking adjustments in unit/Makefile is starting to show in other branches/PRs as well. Thanks!

@thk123 thk123 force-pushed the feature/unit-test-utility branch 2 times, most recently from ee9af0f to 1520cf9 Compare July 18, 2017 09:45
@thk123
Copy link
Contributor Author

thk123 commented Jul 18, 2017

@tautschnig I think I've modified the Makefile in such a way it should work, but I'd appreciate you having another look at it as quite different to before (left in a separate commit for ease of review: da6e6a0 I'll squash once reviewed)

Copy link
Collaborator

@tautschnig tautschnig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

@tautschnig
Copy link
Collaborator

@thk123 Thanks a lot for all the updates; please squash and maybe you can then poke @kroening for a merge?

thk123 added 4 commits July 18, 2017 11:51
Previously the order of the libraries in LIB would effect whether the
unit tests compiled.

Use OBJ rather than LIBS to ensure the --start-group/--end-group flags are
used in linking.

Previously, if a file in CProver changed, though the libraries would be
rebuilt, the unit tests wouldn't be relinked against the new library,
meaning you would get out of date binaries.

This change ensures that the link process is rerun if any of the
libraries are rebuilt.

Adding dependency to cprover libs for other unit executables
Use namespace rather than class with static functions as more semantically
correct.
In turns the error return state into a CATCH exception so the test will
fail without cluttering tests with checks on the flag when it is just setup
code for the actual test.
The auxilary function had the same flags requried for the test, so added
a utility constructor that allows specifying of name and type.
@thk123 thk123 force-pushed the feature/unit-test-utility branch from 1520cf9 to e3f8d4a Compare July 18, 2017 10:52
@thk123
Copy link
Contributor Author

thk123 commented Jul 18, 2017

@kroening All fixed and squashed, could I get a merge as I understand from @tautschnig that the lack of Makefile changes is causing other issues.

@kroening kroening merged commit 6fbd1cf into diffblue:master Jul 18, 2017
@thk123 thk123 deleted the feature/unit-test-utility branch July 19, 2017 08:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants